Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
We some blocks that depend on XSP just because they provide some logigsheets (session, databases etc.), so as soon as you want to use them you *have* to include XSP although you don't use it at all.Forget to say the obvious: this is of course only for trunk.
We discussed this already, but didn't change anything :(
I see two solutions:
1) either move all xsp related stuff into the xsp block and then the xsp block depends on other blocks.
2) create two blocks for each block that supports xsp: for example a databases and a databases-xsp block. Obviously the first one contains the block without logigsheets and is free of XSP and the second one just contains all the XSP stuff, depends on the databases and the XSP block. Et voila.
Leaving it the way it is is really annoying.
WDYT?
3) remove all dependencies on XSP in both directions
+1
Currently we have following dependencies:
"xsp" is needed by "chaperon", "databases", "eventcache", "lucene", "python", "scratchpad", "session-fw".
If you only want to use XSP without all the blocks this is annoying too.
BTW, I hope we can deprecate XSP relly soon - the result of our last discussion was that we need an alternative. In the meantime Daniel and Leszek started to work on the templating block and this should be the solution we have been looking for.
I'm swamped with other work ATM and the same seem to be the case for Leszek, so not that much is happening right now. Other people are of course welcome to continue the work. There is a status/roadmap in http://marc.theaimsgroup.com/?t=110651778400003&r=1&w=2. The refactored JXTG is supposed to be back compatible with the original JXTG but extensive testing is required to verify that. Most of the things that are left to do from my POV only affects the internal APIs, and are needed for making the template compiler and engine reusable for e.g. an attribute template language. But this is not important for the JXTG user, and one don't need to wait for that to be finished before starting to use it.
Maybe we could start to use the refactored JXTG instead of the original in trunk to increase testing and community involvement. We would also get the advantage that the request object etc are accesed in the same way both for flow and non flow usage.
/Daniel