Move JDocument to legacy tree. Not a Deprecation.

[Donald Gilbert]

https://github.com/joomla/joomla-platform/pull/1800

// copied from the PR. Please comment there.

JDocument is so heavily tied to the CMS that it is difficult to use outside of the CMS in it's current state. With the massive namespace effort, I felt it would be appropriate to move JDocument to legacy, and preserve it there for downstream users. IMO, it should be transferred to the CMS altogether, but I want to provide a viable alternative before that occurs.

For or against, let it be known, or forever hold your peace. :) (only partially kidding)

[Amy Stephen]

+1 on moving it. Andrew also recommended this in one of the many NSing posts.

There really is nothing in JPlatform now for rendering unless you are using the CMS type extensions (which means you must also be using the CMS since so much of the code is there.) It'll make no difference for JPlatform users if it's moved into CMS folder.

I believe Andrew intends on checking out Mustache with Rahisi. He's got a basic app there ready to go if someone wants to begin exploring Mustache. https://github.com/eddieajau/rahisi/tree/master/lib

Hooking up a templating environment like Mustache or even Twig is a choice folks could use now.

PS - That someone doesn't need to be your Don. ;-) We can look around, see who might want to explore.

[Andrew Eddie]

On 16 January 2013 17:55, Amy Stephen <amyst...@gmail.com> wrote:

I believe Andrew intends on checking out Mustache with Rahisi. He's got a basic app there ready to go if someone wants to begin exploring Mustache. https://github.com/eddieajau/rahisi/tree/master/lib

Hooking up a templating environment like Mustache or even Twig is a choice folks could use now.

I've already played with Mustache and am quite happy with it. Anthony Ferrara has a good blog post on why it's a good choice as well (it makes you think about your data). Having said that, I also believe now that it's more a choice for the application developer rather than the Platform per se. I wouldn't be happy for us to just slap something in that was half baked and half thought out. It would be better to drop JDocument completely, with no replacement (because it's basically a one-in-all-in deal with the CMS), and then see what people come up with.  If the CMS is happy with that, I don't see a problem.

Regards,

Andrew Eddie

[Amy Stephen]

Yea, but the trick is, how do you tell Mustache what to render?  From there, it's just like pulling a string.

Agree on not slapping things together. Think we might see the line between platform and app somewhat differently.

All. In. Good. Time. 

[Andrew Eddie]

On 16 January 2013 20:38, Amy Stephen <amyst...@gmail.com> wrote:

Yea, but the trick is, how do you tell Mustache what to render?  From there, it's just like pulling a string.

Whatever data the view loads and shoves into the mustache processor.

Regards,

Andrew Eddie 

[Amy Stephen]

Andrew - please do share. Intrigued!

[Amy Stephen]

Along those lines, from David Hurley https://github.com/cobaltcrm/cobalt

It might help with defining the line between application and CMS.

He said he tried to stay close to Jplatform. Obviously he borrowed some of those things that have been classed CMS, but, you'd either have to do that or write new. He also indicated he did write a good deal of code.

As you'll see, he's using JDoc.

It's the most promising example I've seen built from JPlatform. So great to see.

On Tuesday, January 15, 2013 9:57:58 PM UTC-6, Donald Gilbert wrote:

[Alonzo Turner]

Moving JDocument into the CMS would be a huge help to me. I've been working on a better agnostic integration of JavaScript into the CMS. JDocument is the point of entry for all JavaScript added either directly through JDocument, or through JHtml and JFormField and its children which call JDocument indirectly.

Which leads me to point out that JForm is not being removed from the platform, but it directly uses JDocument to inject JavaScript into the document. One example of this is JFormFieldCalendar which calls JHtml::_('calendar'), which in turn calls JHtml::_('behavior.calendar') and JHtml::_('behavior.tooltip'), which in turn call JHtml::_('script') which eventually calls JDocument->addScript().

Moving JDocument out of the platform, might just force us to confront the untangling of certain JavaScript frameworks which are currently so tightly integrated with the CMS. It would also make the platform completely agnostic in rendering an HTML document. I see this as a win win for both the CMS and the Platform!

[Donald Gilbert]

That's a good point Alonzo. JForm and in turn JHtml have a heavy dependency on JDocument. I wonder what we COULD do in this case to achieve the ever-elusive "loose coupling" that we all strive for. This is a brain teaser, for sure.

[Amy Stephen]

Wanted to share this eBook from http://blog.apigee.com/.

We've talked a bit here and there about a services locator, a facade pattern layer, a way to simplify and bring some clarity to the API, and put a cushion between the application layer where people who are calling for stability, and fixing these uncoupling issues under the hood.

The eBook is very good. It gets at just those issues and has some good advise on how to get "from here" to a RESTful API.

Apparently, others might be dealing with these challenges, as well.

[Amy Stephen]

Wrong link - sorry - there are four podcasts on this topic - look at the top-right of the page for links to the other three. Presenter is https://twitter.com/Santanu_Dey

http://apigee.com/about/api-best-practices/essential-api-facade-patterns-part-i-composition

[Donald Gilbert]

For anyone still wondering, we will not be making this change, so you can breath easy.