Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Currently we have two sitemap components, the jxtg and the forms transformer, that are able to evaluate dynamic expressions.
Today I found out, that even these two components use different identifiers: for example if you want to access the continuation id, you use "cocoon/continuation/id" in jxtg. But this doesn't work in the forms transformer. There you have to use "continuation/id". And the annoying part is that this last expression works in jxtg but is deprecated.
I think this is really confusing.
So, anyone against using the same object model in these components? This means introducing the "cocoon" object in the forms transformer and at the same time deprecating the access without the cocoon object.
+1
Another question is, why care about the FormsTransformer at all, does it give us something that we can't get from JXTG + Sylvain's macros?
It's faster, that's one.
The jx:import instruction imports the macros during run time instead of script compile time, thats probably the reason for it being slow. AFAIU there is nothing to do about that as far as we want jx:import to be back compatible. I plan to add a jx:include (or whatever it should be called) to the refactored JXTG, that does much more during compile time. With that it should be fast enough.
It does not support lots of complex stuff jx allows, so your templates will have to be free of any logic, that's two.
That is harder to do anything about as we want to keep everything back compatible. Maybe we should have a JXTG 2.0 that is completely declarative.
I'd prefer FormsT over jx anytime in the current state of things.
Ok
/Daniel
