Custom template vars for MODx Evo

Hey Peter,

Great job man! I wanted to share my current plan on creating a gallery/ order management, etc.

1. How I have been doing it
- I have been using external tables and a module

2. What I plan to do
- I create a folder called Gallery (It’s hidden from the client though)
- Each photo is a modx page. Why? My clients want additional fields linked with their image, and I can use TV’s
- Use your custom TV’s or a module with the modx api to create/edit the modx resources via the API

This way modx handles all the CRUD, but I can layout the gui however I need. The only problems I see are possibly caching. But I can create my on frontend snippet to handle the views if needed.

My general idea: Use modx to manage all the content. Use other libs like Zend lucene, Mongo, h2o-php on the frontend if caching is a problem.

What do you think about this crazy idea?

Quote from: ChuckTrukk at May 13, 2010, 11:07 AM

- Each photo is a modx page. Why? My clients want additional fields linked with their image, and I can use TV’s
- Use your custom TV’s or a module with the modx api to create/edit the modx resources via the API

Thanks Chuck! Your reasoning for using MODx pages makes sense, though I would be concerned about the number of pages in the manager - an external table keeps down the number so the ’soft limit’ should not be reached so easily.

Use custom TVs - the experience will be much nicer than a module (a MODx document becomes the ’Gallery’, and a datagrid allows access to the images)

What do you think about this crazy idea?

Apart from reaching the document limit (which I’ve heard bandied around many times - can anyone explain where the limit’s reached and what causes it?) it sounds a good approach. I’d take a different approach to caching, caching the static HTML rather than the data, but otherwise I agree in principle.

Questions

• MODx is known to get slow with too many documents - is this even if they’re hidden in the document tree? This is one reason I’ve always used an external table
• Ditto extenders - I have heard rumours that these (or something) can allow Ditto to query an external database. Do you know anything about this?

Ditto extenders - I have heard rumours that these (or something) can allow Ditto to query an external database. Do you know anything about this?

Ditto can only query modx-Documents.
But bloX can query both modx-Documents and tables (by default only from same database as modx)
or what else you want to retrieve in your custom getdatas.php-project/task-files.

bloX is included in our Xedit-project:
http://github.com/Bruno17/bloX-Xedit

Quote from: Peter at May 14, 2010, 11:47 AM

Thanks Chuck! Your reasoning for using MODx pages makes sense, though I would be concerned about the number of pages in the manager - an external table keeps down the number so the ’soft limit’ should not be reached so easily.

Apart from reaching the document limit (which I’ve heard bandied around many times - can anyone explain where the limit’s reached and what causes it?) it sounds a good approach. I’d take a different approach to caching, caching the static HTML rather than the data, but otherwise I agree in principle.

Questions

• MODx is known to get slow with too many documents - is this even if they’re hidden in the document tree? This is one reason I’ve always used an external table
• Ditto extenders - I have heard rumours that these (or something) can allow Ditto to query an external database. Do you know anything about this?

From what I’ve seen, the problem with MODx running slow is the siteCache.idx.php gets really large so modx needs to parse a multiple MB size array on each page load. There are some ways to cut this down:
- make all chunks, snippets, and plugins load external files (then these arrays only take up a few bytes). For snippets, use the Includes snippet so they’re not even in the db.

The other main problem we could run into is the aliasListing array in the siteCache.idx.php could become really large. I dont know what we could do to fix this yet, but if we solve this, I think we’re in business to use MODx CRUD magic.

Regarding Ditto, I use my own little getResources snippet and h2o templating to grab the data and cache the HTML output.

Quote from: ChuckTrukk

2. What I plan to do
- I create a folder called Gallery (It’s hidden from the client though)
- Each photo is a modx page. Why? My clients want additional fields linked with their image, and I can use TV’s

Quote from: Peter

Yes, eCommerce is definitely coming; we may be developing an image gallery using this system next month for a client, but they haven’t decided if they want it yet. Have you any thoughts on the gallery UI? Previously when we created a new document type for a gallery we put all images on the page, but I’m not convinced this is the best approach with custom template variables as the page could get very long. Doing it in a lightbox would be an alternative, but from a user perspective is one more ’hoop’ to jump through.

If I’m understanding correctly it sounds like I’ve been doing the same thing as ChuckTrukk for image galleries and lightboxes; using a MODx docs inside a folder as an image then using Ditto to call these into a lightbox. It’s a bit clunky but it works, and the client can reorder/rename the images and add an infinite amount of images to a gallery.

But, your TV-based solution seems a lot more intuitive; not only would it bring the overall MODx doc count down but its more self contained and manageable.

The UI interface you linked to on the previous page looked great, I couldn’t see any big problems with it; one thing I would try and add it some AJAX dragging and dropping for reordering the images; which would make the whole process much easier for the client. Other than that it looks great

I’ve still not been able to get your Custom TVs code to work but would it be possible to just install the image gallery TV, or make this a separate plugin? Will you be releasing a fix for those who can’t get it working?

Quote from: Adam at May 15, 2010, 10:04 AM

The UI interface you linked to on the previous page looked great, I couldn’t see any big problems with it; one thing I would try and add it some AJAX dragging and dropping for reordering the images; which would make the whole process much easier for the client. Other than that it looks great

Drag and drop was coming, but for the one I showed you the budget didn’t stretch far enough

I’ve still not been able to get your Custom TVs code to work but would it be possible to just install the image gallery TV, or make this a separate plugin? Will you be releasing a fix for those who can’t get it working?

I’ll be releasing a fix as soon as I find time - paying customers have to come first!

Peter

Adam, I’ve posted a new release which will work for you - I’ve tested it in a subfolder of the webroot.

Quote from: ChuckTrukk at May 14, 2010, 05:48 PM

The other main problem we could run into is the aliasListing array in the siteCache.idx.php could become really large. I dont know what we could do to fix this yet, but if we solve this, I think we’re in business to use MODx CRUD magic.

I believe that this is the wrong place to solve performance problems. For most sites where people aren’t logging in, the optimisation would be better moved a stage forward, to output caching of the generated HTML. siteCache.idx.php may be large, but with a PHP bytecache the amount of code being loaded is only on a par with other frameworks.

It would be nice to improve the performance by decreasing the size of siteCache.idx.php, but this needs quite a bit of work and testing on the MODx core. What I’ve yet to see though is any hard numbers, for the speed of the site vs size of this file - or any reports of real problems. I’ve checked all my sites, even one with thousands of pages getting a visit a second on cheap shared hosting, and they don’t have any noticeable issues.

Creating an image gallery using custom TVs has created a teaser of a problem... when should changes to the images (e.g. adding new ones, deleting other, changing captions & settings) be saved to the database?

Programming-wise, the easiest approach is to save the changes as soon as the image gallery is updated. However, this breaks people’s expectation that the ’Save’ button on the page will do what it says, and they can revert to the old version until they click it.

Which means that every update in a lightbox, every drag ’n drop reordering can’t save directly to the database, as this would preserve changes even if they hit ’Cancel’.

When you’ve demo’d MODx to your clients, what has their expectation been? I can write something clever and temporarily save the data until the ’Save’ button is clicked, but would your clients really notice the difference?

It doesn’t work for me. I have downloaded and installed it today. I did create a custom "FAQs Selector" TV but when I try to access it from the document it throws the classic "The requested URL /assets/tvs/faqs/popup.php was not found on this server." (The file exists and has 777)

I’m running from http://server-ip/modx from an ubuntu server