[HACK] Custom document types in the document tree

Great, thanks; I see what you are wanting now...

Let me clarify how this will be addressed in the future, so there are no surprises. Some of this will reveal our 1.0 roadmap, which I’m trying to find time to publish formally (sigh).

First, in 1.0, Documents (which I will refer to as Resources, since they represent any web resource accessible by a URI) will be represented by classes and can represent a lot of different things, from links, to typical pages, to AJAX request handlers, to SOAP handlers. Document Types as they are now, will become the Resource classes and will define all the data to be persisted for and the behavior of that class of Resource, overriding only what it needs to in order to accomplish it’s extended purpose.

Second, in 1.0, manager pages can be standard PHP pages that can access the MODx object (aka controller) just like the standard front-end pages do, or however they decide to. This means they can take advantage of the parser if they want to (or not), use individual snippets or other Elements (in 1.0, all currently named MODx Resources, such as snippets, chunks, TV’s, plugins, and modules) directly; in other words, a PHP page can have all the advantages of a page managed in the MODx database as a Resource.

Finally, the user systems and permissions will be integrated in 1.0. No more web users vs. manager users. A user is a user is a user, and they have permissions that apply at various scopes in the site. Thus, in 1.0, you could decide to implement a manager interface along with the standalone manager php pages, or create an interface just like you would for the front end, from your existing manager pages, in a secure context of the site (i.e. you might divide a site into a public site and a private, secure extranet site, which would be different site "contexts" in 1.0, but more on that soon).

This means, the manager will be a completely customizable interface at your disposal, modules essentially become just another way of attaching a content element (any kind of content) to a web resource, and you could accomplish all of this by simply creating a MODx page as usual; and you probably wouldn’t even need a custom Resource class to handle it, though nothing would stop you from implementing such.

I hope that vision of things to come in MODx helps you in your decisions when choosing to hack the current system in this regard.

Quote from: OpenGeek at Apr 27, 2006, 12:51 PM

Great, thanks; I see what you are wanting now...

Let me clarify how this will be addressed in the future, so there are no surprises. Some of this will reveal our 1.0 roadmap, which I’m trying to find time to publish formally (sigh).

First, in 1.0, Documents (which I will refer to as Resources, since they represent any web resource accessible by a URI) will be represented by classes and can represent a lot of different things, from links, to typical pages, to AJAX request handlers, to SOAP handlers. Document Types as they are now, will become the Resource classes and will define all the data to be persisted for and the behavior of that class of Resource, overriding only what it needs to in order to accomplish it’s extended purpose.

Wow, that’s really awesome! That was ’kinda’ the thing I was trying to create (as in, MODx 1.0 is better). Though MODx, in it’s current form, doesn’t support that. And, we’ll you know clients; they rather see it finished yesterday . So, in order to come up with a ’clean’ solution, this was the easiest thing to do for me, so I could achieve my goal. And in it’s current form, this solution seems fine. But, as you point out, it isn’t all that flexible.

I would’ve used the Resource system if it were available today, sad enough for me, it wasn’t.

I hope that vision of things to come in MODx helps you in your decisions when choosing to hack the current system in this regard.

It surely does but, as stated above, clients don’t know "waiting". I know I probably end up rewriting a big deal when 1.0 comes out, but as I don’t have any indication on the progress made on the 1.0 release (hell, 0.9.2 and 0.9.2.1 even came as a suprise, though that could be because I’m a bit of a newbie around here ). And I couldn’t find a way to contribute or read code from SVN I’m a bit in the dark. I’d love to help, but I know I’m still rather unknown here, so that’ll make it more difficult for both you and me.

Quote from: PrisonerOfPain at Apr 27, 2006, 01:14 PM

It surely does but, as stated above, clients don’t know "waiting". I know I probably end up rewriting a big deal when 1.0 comes out, but as I don’t have any indication on the progress made on the 1.0 release (hell, 0.9.2 and 0.9.2.1 even came as a suprise, though that could be because I’m a bit of a newbie around here ). And I couldn’t find a way to contribute or read code from SVN I’m a bit in the dark. I’d love to help, but I know I’m still rather unknown here, so that’ll make it more difficult for both you and me.

Understood completely on the clients don’t wait; just keeping you informed.

Actually, I think the time period between 0.9.1 and 0.9.2 releases was the longest cycle since the project started about just a little over a year ago. And we were originally planning on skipping 0.9.2 and going straight to 0.9.5, but I got impatient in addition to the security issues that were revealed. 0.9.5 will follow shortly and will include a lot of cool new features, new default content, and a manager skinnable via a single CSS file. We;re just polishing it up right now.

1.0 is under development, but may be a few months off still, as it will require a lot of new documentation and related efforts, but the new core code is about 60% completed to give you hint.

As for contributions and SVN access, we are in the process of reorganizing the team internally, developing formal development guidelines, and performing other infrastructure tasks in preparation for announcing public SVN access and more ways to contribute to the project.

Quote from: OpenGeek at Apr 27, 2006, 01:32 PM

Understood completely on the clients don’t wait; just keeping you informed.

Thanks for that . And a little compliment from my side, as for the responsive- and openness of the project (and community)! I think I’ll stick around a bit longer .

Btw, as for the 1.0 release, is it still based Etomite? (Etomite has become more a foe than a friend when it comes to it’s sourcecode, that’s why I came to MODx in the first place ).

1.0 is a total original rewrite of everything. It will also be released under a less restrictive license, too (LGPL or BSD most likely).

Quote from: PrisonerOfPain at Apr 27, 2006, 12:17 PM

It doesn’t have anything to do with the MIME-Type, nor the Content-Type. The purpose I built this hack was to be able to place my clients photo gallery directly in the content menu. Normally you would’ve done that with a snippet which you just pass parameters to ([!PhotoGallery?galleryid=15&....!]) but I wanted the gallery to be controlled (and created) from within the normal MODx GUI.

I had a similar need. I solved it with in another way. Maybe it’s usefull for other people. My editors can create a subfolder on the website through FTP and place all images for the gallery there. I have the following structure on the FTP:

root
- documents
- images
--Holiday
--birthday

Then the editor creates a new page and selects the template called "Gallery" (normally "Webpage" is used). That template has a TV with an @EVAL binding which just returns a list folders available in in the images folder (Holiday and birthday in this example). So when editing the page the user gets a dropdownlist with all available folders (==galleries). The editor can select one gallery that has to be shown in the page. In the template I have a call to my gallery snippet that takes the value of the TV as input and shows all images in the folder that is defined in the TV.

I do realize that this uses FTP instead of only the MODx GUI, but I think the editors can also upload images through the filemanager. The reason I opted for FTP is that it is easier for the editor to upload lots of images in one go.

<--*Gogles open mouthed at OpenGeek* Holy smoke, you have got to be kidding me. THAT is what you guys are cooking up? Un-frickin-beleiveable. How amazing can MODX get? I am salivating nastily.

Stop your slobbering. That’s not polite!

We might actually mess up and make MODx 1/2-way decent.

Hi!
I just posted a thread in the wishlist subforum about a media manager.
It really was about being able to manage non-database items (such as images, or other files) from the standard modx system, in order to assign them permissions and other properties.

Then I just read this thread!

From what I have understood, it would be possible to define a custom document type that is a record for a file stored in the server. Something like a weblink but that points to a file and allows custom properties to be defined.
Then those documents could be searched and it would be possible to retrieve a list of the files that match certain criteria.

¿Have I misunderstood the 1.0 goals?

Wow! I really can’t wait for 1.0!!!