Re: [RT] Remove dependencies to XSP
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. 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? Forget to say the obvious: this is of course only for trunk. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Remove dependencies to XSP
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. 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. This just moves the problem to the XSP block, as you'll need to include all blocks that provide XSP features even if you need only one. 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. +1. This adds more blocks, but I can't see another way to cleanly separate things. In the particular case of the database block, can't we move all the esql stuff in the XSP block, as JDBC is a core JDK feature and doesn't require external libraries? Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Remove dependencies to XSP
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. 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? Forget to say the obvious: this is of course only for trunk. 3) remove all dependencies on XSP in both directions 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. -- Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach {Software Engineering, Open Source, Web Applications, Apache Cocoon} web(log): http://www.poetz.cc
Re: [RT] Remove dependencies to XSP
Hi, On 9 Feb 2005, at 09:20, Carsten Ziegeler wrote: 2) create two blocks for each block that supports xsp: for example a databases and a databases-xsp block I suspect this is the easiest option. Forget to say the obvious: this is of course only for trunk. Hmm - any reason why it can't happen in BRANCH_2_1_X too? It's not a change in functionality, afaict... Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Remove dependencies to XSP
On Mie, 9 de Febrero de 2005, 4:52, Andrew Savory dijo: > Hi, > > On 9 Feb 2005, at 09:20, Carsten Ziegeler wrote: > >>> 2) create two blocks for each block that supports xsp: for example a >>> databases and a databases-xsp block > > I suspect this is the easiest option. > >> Forget to say the obvious: this is of course only for trunk. > > Hmm - any reason why it can't happen in BRANCH_2_1_X too? It's not a > change in functionality, afaict... +1 Best Regards, Antonio Gallardo
Re: [RT] Remove dependencies to XSP
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. 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? Forget to say the obvious: this is of course only for trunk. 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=11065177843&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
Re: [RT] Remove dependencies to XSP
I just did a check which blocks require xsp: - "python" Uses the xsp core, so this is ok - "chaperon", - "lucene" - "eventcache" All these three use xsp just for the samples, so we should imho simply rewrite the samples. - "databases" - "session-fw". These two are the only blocks that have own logigsheets. - "scratchpad" Don't know why this depends on XSP. Anyone? So I would suggest to rewrite the samples and simply move the logicsheets to the xsp blocks; imho it's not worth creating new blocks just because of these two logicsheets. WDYT? Carsten 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. 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? -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Remove dependencies to XSP
Il giorno 09/feb/05, alle 18:37, Carsten Ziegeler ha scritto: So I would suggest to rewrite the samples and simply move the logicsheets to the xsp blocks; imho it's not worth creating new blocks just because of these two logicsheets. WDYT? +1 -- Ugo Cei - http://agylen.com/blojsom/blog/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Remove dependencies to XSP
Carsten Ziegeler wrote: I just did a check which blocks require xsp: - "python" Uses the xsp core, so this is ok - "chaperon", - "lucene" - "eventcache" All these three use xsp just for the samples, so we should imho simply rewrite the samples. - "databases" - "session-fw". These two are the only blocks that have own logigsheets. - "scratchpad" Don't know why this depends on XSP. Anyone? So I would suggest to rewrite the samples and simply move the logicsheets to the xsp blocks; imho it's not worth creating new blocks just because of these two logicsheets. WDYT? +1 -- Stefano.
Re: [RT] Remove dependencies to XSP
Antonio Gallardo wrote: On Mie, 9 de Febrero de 2005, 4:52, Andrew Savory dijo: On 9 Feb 2005, at 09:20, Carsten Ziegeler wrote: 2) create two blocks for each block that supports xsp: for example a databases and a databases-xsp block I suspect this is the easiest option. Forget to say the obvious: this is of course only for trunk. Hmm - any reason why it can't happen in BRANCH_2_1_X too? It's not a change in functionality, afaict... +1 +1 Vadim Best Regards, Antonio Gallardo