Hi Matteo, >I think that if a Java engine already exists for a certain language, it >should not be so impossible to support, with all constraints and limits, >another templating language.
at first you must differentiate what concern PHP should address in your setup. At this point you call it just "templating language". In this scope PHP syntax itself is not seen as the golden hammer. Here many PHP web and cms projects resort to a actual simple syntax of its own. Smarty templating language[1] might be the exact counterpart to Freemarker in Magnolia. That stuff deliberately restricts to key features (content placeholders, iterations) that solely address the view, and can prohibit a developer to clutter logic into the "pages"(templates). Before I understood the other extreme, that is you want to use PHP as a whole to build somehow magnolia-based webapps. For this you have to decide basic architectural problems, beginning with the question what will be the leading webapp with primary control of the request/response cycle (the PHP preprocessor itself?). This is hard enough in integration of other Java webapp frameworks with a cms like magnolia, and leaving the Java ecosystem wont make it easier. That also comes to solutions with several trade-offs, high complexity at least. I do not think that a PHP support in the context of Magnolia is possible that makes distinctive Magnolia features available and at the same time lets a PHP developer code freely away like in his own webapp. Nonetheless I can see a viable option to leverage magnolia admin interface as a ui for the content repository and make that JCR itself available (by webdav?) for whatever webapp or component, but I suppose there will not be enough Magnolia left in the architecture to actually call it Magnolia based. If you are at this point you may find the content repository paradigm also present in generic PHP projects (just google it), so it would not make sense to keep any Java in the game. That fraction between Java and PHP in one project would suck anyway. I also can see an option in using Sling[2] as a content repository backend, with that you are still using a Java part and JCR, although you probably will use it as a standalone content repo. There are presentations you find on the web where the Day guys demonstrate a DHTML rich client in the browser using Sling in this way. Stuff like this may be possible with PHP, but this is quite low level and not really a fully fledged CMS - which you might start to write then? ;-) Regards j [1] http://www.smarty.net/ [2] http://sling.apache.org/ ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
