Xedit and MultiTV

I have heard there is a namespaced version of mootools, but my understanding was it was not an official distribution... I have nothing against mootools and I am not suggesting to start back from scratch, just thinking it would be a shame to have a great tool with Xedit causing js conflicts and/or not working because of the $ thing (not that I would be in that case since I only use jQuery and can avoid conflict).

Found this via Twitter btw.

Wow, this is impressive. I think it really becomes useful in a live setting when the ability to retain the layout on returning to the page is created. Any plans to work in that direction?

I really like the idea! Will it be possible to say what chunks may be used in a certain area of your page? So that I can use different chunks for the left and right sidebar?

Very nice, saw this on Twitter, don’t know enough yet to be able to ask intelligent questions , but I’ll be back

Truly awesome,.. I meant to be in bed by now but I just can’t stop playing with the demo If I wasn’t living on the other side of the world I’d knock on your door and give you a hug! I love it.

(hmm,.. come to think of it, perhaps it’s a good I’m living here... )

Thanks for your input!

Before I answer the questions, please keep in mind that this is a only concept yet where we can decide in which direction this will go. So any comments are appreciated!

Is it my impression or can you make certain ’blocks’ editable while others are dragable but not editable?

Yes. You can define for each container in general or every chunk in special what can be done by whom. Every MultiChunk (sic!) container is called by a snippet, for example:



another call somewhere else in the template/document:



I think you get the idea. Two calls somewhere in the template. The first container can be filled with the mentioned chunks, each with individual settings.

The second container can only be filled with one chunk. Since they are grouped, the common chunks can be dragged and dropped between the two containers.

Remember: This is brainstorming, no single line of code is written yet (well, not really true ;-) ).

Any time scales when we can start playing with this in MODx?

When it is ready ;-) No idea at the moment, we have to talk about the best way to implement these new kind of Chunks and multiple TVs without hacking something.

Just one question; the name MultiTV implies that there are multiple TVs but it seems to be more like MultiChunks. Am I missing the MultiTV concept? Is it multiple views of the same TV? So if I have a TV with the value ’hello’ I can use it to return the same value x number of time or am I able to use it multiple times with different values?

Well, multiChunk is also correct. But technically the chunks dont need to be stored several times, since they only build templates. But if you put in 5 times the same chunk with the same TV, the TV has to be stored 5 times... somehow. This is the main thing we are discussioning in the german forum. I thought about an extra multi-TV table where the values are stored if a TV is called multiple times in a multiTV/Chunk container. This could be done with a plugin which renders this onWEbPagePrerender. Bruno had another idea with storing them as child documents where each multiChunk is a Document. We have to investigate this but I think we will find a solution. So back to your question:

or am I able to use it multiple times with different values?

Exactly. You only need one TV of each kind (advantage: TV management stays the same). The values can be multiple. I thought about a "@multi" in the standard value form for identifying the TVs that can be used multiple. We`ll see.

I think it really becomes useful in a live setting when the ability to retain the layout on returning to the page is created. Any plans to work in that direction?

I dont really understand the question. Idea is to put some more management possibilities in the frontend. The user can edit, sort drag around in a 1:1 view of his website till he is satisfied with the result. There will be a "overall save button" which saves all changes done so far. After that the page is rerendered and the user can go on. I would like to combine this thing with the contenthistory plugin from stefan. With that the user can save drafts until he is satisfied and then "publish" it with the possibility to revert each stage in the process.

Other ideas are: Creating documents, adding subdocuments, even editing ditto entries should be possible.

Will it be possible to say what chunks may be used in a certain area of your page? So that I can use different chunks for the left and right sidebar?

I think these questions are answered above. So yes and yes.

OK I did some work on this and have it run in modx.
Have written a plugin for sorting and editing this "multiTVchunks" in the manager and a snippet which calls ditto with special parameters for showing the chunks in frontend.
the part in my template now looks like this:



You can see it running this way in modx here: http://www.goldschmiedeinnung-unterfranken.de/testmodx/index.php?id=24

My solution autocreates for each block of the page an subfolder called left,right,middle in this case. Then for each chunk an own document. So you can use the documentfields and tvs for storing the chunkdatas and I can use ditto for dispaying the datas. My snippet looks before calling ditto for all needed tvs, stores them in &hiddenfields manipulates the chunk for use with xEdit and says ditto which chunk to use for each row.......

Bruno

@Bruno - Now you have me drooling like a dog!!! Simply brilliant!

This is awesome. I am a fan of jquery, but who cares- i can include moo and jquery.noConflict() on the same page to allow this. I mean this is GREAT.

For implementation, I like the idea of creating a seperate table for these. Specifically for the cache issues and to keep the doc tree clean.

Great idea.

For implementation, I like the idea of creating a seperate table for these. Specifically for the cache issues and to keep the doc tree clean.

Yes, these were my arguments, too. But Bruno`s approach has some advantages:

- Display the chunks relatively simple by using Ditto.
- Content can be found by AjaxSearch (has to be forwarded to the parent doc though)
- Use the standard API functions for manipulating the data

Regarding the tree, we thought about hiding them in the tree either by a button for collapse and extend the sub docs, collapsed would be standard. Or hiding them by default with setting the parent to a negative value (-id).

edit: Just realized that even dragging and dropping single images, text and copy&paste between the chunks works ;-)