Rethinking MODx

Quote from: JoeP at Nov 07, 2006, 06:43 PM

RIGHT ON!!!
This is Totaly clear (to me... I think... or maybe I just want it to be soooo bad)! You have an element. An element can be placed anywhere in any document. Each element can have its own properties, behaviors (methods), etc... kind of like an object. When the document is parsed, the element will display it’s properties or execute its behaviors according to its definition, context and messages it’s passed. Obviously, an element can contain an element, can contain an element, etc. Is that the idea?

Yes, that’s basically it in a nutshell.

Quote from: JoeP at Nov 07, 2006, 06:43 PM

In my crude home brew system I used the element concept(very rough though). For example, I have a weather forecast element. You can put the element anywhere. If you call it one way you get a one-day forecast, call it another you get 6 days. The element itself spits out all the HTML, including the appropriate CSS class, to display the element. In something like MODx I’m guessing you could go several steps further by doing things like checking the width and height of the div or size of the cell that you had available and make adjustments accordingly.

Sure, you could create visual-oriented elements that did such things, but I maintain strict isolation of the style, content, and logic in my sites because I believe it is essential to maintaining a site over the long-term, so I generally use script elements (snippets/plugins) to produce my content via other elements used as templates (chunks/templates), and in the case of HTML output, style it via an external CSS file or dynamic CSS file generated by another MODx resource. Or with XML, I might apply an external XSL file, or dynamic XSL file generated by another resource.

Quote from: JoeP at Nov 07, 2006, 06:43 PM

I’m a MODx newB and my biggest stumbling block has been the lingo. Thins like "Template Variable" that is given a "Value" have completely thrown me for a loop!
I hope I’m not completely out in the weeds again,
joe

I think you’ve got the concepts and we agree, the lingo has been a source of pain for the project. But it will soon be history...

Quote from: identity at Nov 07, 2006, 09:48 AM

I agree that I think there should be some standards for the contributed items, like snippets, etc.

Perhaps the repository could have a two-tiered setup and some kind of stamp of approval... (...) Something that shows that a snippet has been reviewed by the core team to show that the code is sound, future compatible (at least as much as possible, which might just mean till the next release), and has met a certain minimum of standard requirements.

Perhaps what would help to manage and track add-ons to MODx -- snippets, modules, themes etc. -- is to introduce tickets. I mean every snippet or plugin would have to be registered, as it is now while adding it to the repository, to receive a unique ID. This ID along with other mandatory identification information -- snippet name, version, last modification date, author credentials and contact information, URL to repository, URL to documentation in wiki, and summary -- would have to be included in a separate file.

This would help tracking add-ons by the team and users, help assuring consistent meta data and implementing automatic notification about changes to the add-on directly from inside the manager. It would be of much help to maintain add-ons reach site. I saw this implemented in Xaraya and it seemed very practical and useful, yet easy to achieve. The meta information file could be built with XML to further help consistency.

:o
OO model sounds great ! It seems to be a really different philosophy .

So, can you confirm that an update of version 0.9 towards version 1.0 will be possible ?

Quote from: Olivier at Nov 08, 2006, 03:04 AM

So, can you confirm that an update of version 0.9 towards version 1.0 will be possible ?

Yes, one way or another there will definitely be a converter that prepares your MODx data for the big move - this is likely to come out *after* early betas of 1.0. A lot of us have 0.9.x sites that we’d like to upgrade and so I fully expect an updater.

Jason, are there any best practices that people should get used to using now? Like, do the various elements use the same namespace? If I have a TV called Author and a snippet called Author and a chunk called Author and a template called Author, do I need to make the names unique?

ummm... uhhhhh... in the kindest, gentelest way can I ask...
When? When do you think we might get a peak at the re-thought MODx? Are we talking weeks, months, more than 6 months?
Just trying to decide how much effort to put into the current version.
Thanks,
joe

JoeP,

Since Jason first mentioned 1.0’s new concepts, I too have wondered when the veil may be lifted. I would love to have a rough window so I might plan my development projects accordingly.


That being said, who wants to make a promise they may not keep.

ATB,

Jay

I would not think of asking for a promise, or interpreting a rough estimate as being one. I’ve got way to much time under my belt to be so nieve as to think that an estimate is anything like a committment (or that a committment is anything like reality ). Just trying to get a feeling for intent to help guide my own decisions.
That said, I do understand reluctance to be perceived as making a committment when none can really be made.
joe

I would not think of asking for a promise, or interpreting a rough estimate as being one.

I didn’t think you were. I just stated it so that Jason would feel that MODx apprentice’s like me didn’t think we were expecting one. Anyone, who works with OS apps knows that dev schedules are filled with hope and riddled with amendments.

ATB,

Jay

Let’s just say the breakthrough between the 0.9.x branch and the 1.0 branch might not be as brutal as you might think. There will be some intermediary leaps, as you shall see. Good things comes to those who wait

Quote from: smashingred at Nov 08, 2006, 07:51 AM

Anyone, who works with OS apps knows that dev schedules are filled with hope and riddled with amendments.

And anyone who works with MODx knows this project is running like a runaway train since day one. We’re not your typical OS project there, though as any other project delivery can not be guaranteed for as complex a task as releasing a new codebase is... Yet, I wouldn’t worry too much. Things are moving forward. Look at 0.9.5 and compare it to 0.9.2.1. The gap is significant already. I am very confident in the dev team’s ability to deliver. Now I understand MODx users yearning for a timeframe but I think this team’s work is about doing things right not doing things fast (though you can bet work will go as fast as it can : and BTW, if you want to make it even faster, donations won’t hurt )

Back to the upgrading concern : even if switching to the 1.0 branch means some effort, I don’t think a MODx project should be delayed until 1.0 is out. MODx already is one of a kind and truly has few if not no competitor as far as flexibility is concerned (at least, IMHO). I think you can also trust that upgrading will be thought out, though we can’t of course guarantee that you won’t have to work a bit to make things run identically after the upgrade. But this has to be expected since we’re talking major leap there.

Oh, I forgot : one must-read thread from Jason about future-proofing apps developed on current framework

Here’s a rough timeline without dates so you can draw your own conclusions:

Also note that version numbers are subject to change.

0.9.5 RC2
0.9.5
0.9.7 beta 1
0.9.7 beta 2
0.9.7 beta etc
0.9.7 RC1
0.9.7 RC2
0.9.7
1.0 beta 1
1.0 beta 2
1.0 beta etc
1.0 RC1
0.9.7 > 1.0 Upgrade Tool
1.0 RC2
1.0

So, 1.0 is sometime in 2007. Probably.

And yes. Launch your site now - and take the upcoming release of 1.0 as an opportunity to rethink your own site.