On 28.03.2011 13:30, Jochen Fliedner wrote:
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).
I agree.. and disagree.
I know Smarty and Freemarker. And I can say that in Freemarker you can
still "inject" logic. And Magnolia "officially" support it, for
instance, take a look at stk (STKTemplatingUtils) or mgnl
(MagnoliaTemplatingUtilities) freemarker wrapped object: they can do
queries! Inside Freemarker! And it is what can, indeed, let a team to
cooperate whith less effort.
In Freemarker is possible to inject java object that can for instance
contact webserver, update a database with simple "dot notation".
I *guarantee* that in real case implementation this approach is often be
taken, because not every person in the team can afford pure Java coding.
But they are familiar with "quick" scripting and dot notation.
We can discuss a lot about this point (pure mvc approach, theorical java
ecosystem vs. real projects and money..), but it is not the scope of
this "thread".
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.
Yes. Sure. But think about integrating an external simple
database-driven webapp. With direct mysql php functions, a lot of
queries, parameters checks, validation...
If quercus (or whatever) can handle it, with all the constraints and
situation-driven requirements, I think that it is possible to handle an
application migration with less effort.
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.
Uhm.. I don't want to bypass Magnolia.
Magnolia "green bars" are JS based! Why not having a PHP little
framework for MainBar, EditBar and NewBar? We can use Magnolia pages
togheter with PHP based paragraph/templates. And we can have different
approaches: one part of the team working on Java+Freemarker, an external
team that is more confortable with PHP that implements paragraphs in
that language, another team that brings to Magnolia managament legacy
PHP-based webapp... and so on, and so on.
I say that is not a theoretical "generic good approach".
But in some real cases it can be a requirement-driven best choice.
It's only my opinion, anyway.
Matteo
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
