Re: review of sitemap component documentation
Le 2 déc. 04, à 04:32, David Crossley a écrit : Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html big big thanks for making this happen, it is an important step I think. Hope to find time to help here. Maybe a periodic nag email to here with the number of unreviewed entries would be good? And/or a single bugzilla issue to keep track of the work done on this table might be good? Did you document the process already, i.e. how do new entries come into the table when someone adds a new component? (I have not reread the whole thread so I might be missing something obvious, please bear with me). -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: XMLSerializer replaces tabs with #9;
On 2 Dec 2004, at 07:20, Stefan Pietschmann wrote: I already sent this to the users list but was asked to redirect this problem to the dev list, so here it is: Instead of the normal tab indentation of my xml files, all files serialized by the XMLSerializer have the tabs replaced with #9; entities. The source of an xHTML-file which is returned now looks like this: ... #9;#9;table snip/ So, please help me to get my normal tab back! ;) I see the same problem. Cocoon 2.1.7-dev on Java 1.4.2_05 MacOSX. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: review of sitemap component documentation
Bertrand Delacretaz wrote: David Crossley a écrit : Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html big big thanks for making this happen, it is an important step I think. Hope to find time to help here. You already are. Maybe a periodic nag email to here with the number of unreviewed entries would be good? The xdocs source for that doc is consistent and has some xml comments. It could be parsed and grepped with standard UNIX tools or could be processed with an ant task and XSL. I do want to use tools to help process the xml table. For example, i have a 'sed' script to add a blank column. Should i commit those somewhere? And/or a single bugzilla issue to keep track of the work done on this table might be good? Not sure what you mean there. I was expecting that just the svn commit log messages would suffice. However, i was wondering about using Bugzilla to assist somehow. Perhaps have one bugzilla entry per document, then have a parent issue that creates a roadmap from the child issues. Each issue would enable people to add patches or even comments about that particular sitemap component. Did you document the process already, i.e. how do new entries come into the table when someone adds a new component? (I have not reread the whole thread so I might be missing something obvious, please bear with me). Good questions. I do have a local work log of the steps, so that i can repeat it later. My inial goal was to set up a functional table manually, then work on ways to automate its population and ways to ensure that it stays synchronised. I developed some basic UNIX shell scripts to scan the code and xdocs. The output was manually reviewed to weed out some cruft. After an initial automated load, rows were added manually with copy-and-paste. The next steps are in the To Do list at the bottom of that coordination page. Let us take it steadily. It is a long road. --David
Cocoon-2.1.X Tests Failure 12/02/04
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20041202.log Last messages from the log file: == Testsuite: org.apache.cocoon.serialization.XMidiSerializerTestCase Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.225 sec Testcase: testMIDISerializer took 2.921 sec cocoon-block-webdav-tests: Created dir: /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Copying 3 files to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Compiling 1 source file to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/blocks/webdav/test Running org.apache.cocoon.components.source.impl.WebDAVSourceTestCase Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.37 sec Testsuite: org.apache.cocoon.components.source.impl.WebDAVSourceTestCase Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.37 sec - Standard Error - log4j:WARN No appenders could be found for logger (org.apache.commons.httpclient.HttpClient). log4j:WARN Please initialize the log4j system properly. - --- Testcase: testResolve took 1.925 sec Testcase: testTraversal took 0.052 sec Testcase: testModification took 0.038 sec Testcase: testMakeCollection took 0.056 sec junit-tests-report: Created dir: /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/report Transform time: 53691ms Unit report is at build/cocoon-2.1.7-dev/test/report/index.html Last messages from the server console: == [EMAIL PROTECTED]: [Thread[Thread-4,5,main]]: checkRunning(false) entered [EMAIL PROTECTED]: [Thread[Thread-4,5,main]]: checkRunning(false) exited [EMAIL PROTECTED]: Startup sequence initiated from main() method [EMAIL PROTECTED]: Loaded properties from [/disk/raid0/home/vadim/svn/cocoon-2.1.X/server.properties] [EMAIL PROTECTED]: Initiating startup sequence... [EMAIL PROTECTED]: Server socket opened successfully in 4 ms. [EMAIL PROTECTED]: Database [index=0, id=0, db=file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db/cocoondb, alias=] opened sucessfully in 2577 ms. [EMAIL PROTECTED]: Startup sequence completed in 2647 ms. [EMAIL PROTECTED]: 2004-12-02 01:30:15.998 HSQLDB server 1.7.2 is online [EMAIL PROTECTED]: To close normally, connect and execute SHUTDOWN SQL [EMAIL PROTECTED]: From command line, use [Ctrl]+[C] to abort abruptly - The database 'db' root directory has been set to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db. Keep in mind that if a war upgrade will take place the database will be lost. - Database points to /disk/raid0/home/vadim/svn/cocoon-2.1.X/build/webapp/WEB-INF/db - [main] '/db/system/SysSymbols' Set object system_SysConfig - [main] '/db/system/SysConfig' Set document database.xml - [main] '/db/system/SysSymbols' Set object meta_Metas - [main] '/db/system/SysSymbols' Set object meta_Metas_system_SysConfig - Database 'db' successfully opened - Xindice server successfully started - VM shutting down with the disk store for cocoon-ehcache-1 still active. The disk store is persistent. Calling dispose... - Database 'db' successfully closed - Scheduler Cocoon_$_Thu_Dec_02_01:30:02_PST_2004 paused. - Scheduler Cocoon_$_Thu_Dec_02_01:30:02_PST_2004 shutting down. - Scheduler Cocoon_$_Thu_Dec_02_01:30:02_PST_2004 paused. - Scheduler Cocoon_$_Thu_Dec_02_01:30:02_PST_2004 shutdown complete.
Re: [CForms] How to iterate other a model?
Stephan Coboos wrote:
Hi Sylvain,
I have resolved my problem: I have to include the v2 Form.js and to
change form.getModel() to form.getWidget().
Thanks.
Well, don't thank me, I was of little help in finding the solution ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: review of sitemap component documentation
David Crossley wrote:
Okay the initial coordination table is now ready.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
Wow, impressive work!
The next task is to review the table to ensure that
all entries have been added for sitemap components.
Another impressive work to do ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: review of sitemap component documentation
Great! Thanks for doing this. Bye, Helma -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED] Sent: Thursday, 02 December, 2004 04:32 To: [EMAIL PROTECTED] Subject: review of sitemap component documentation Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html The next task is to review the table to ensure that all entries have been added for sitemap components. --David
DO NOT REPLY [Bug 28724] - FragmentExtractor always returns same fragment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28724. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28724 --- Additional Comments From [EMAIL PROTECTED] 2004-12-02 11:12 --- Hi Dean, hi Joerg I checked your proposal (getQueryString()), bu as you wrote, it didn't work because I send a POST request. I think, we close the bug with my solution ad interim. If Cocoon is going to have the parameters through the whole pipeline, we look for a fine solution. What do you think? Sarah -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: review of sitemap component documentation
superb effort David thanks! Cheers Jorg David Crossley wrote: Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html The next task is to review the table to ensure that all entries have been added for sitemap components. --David
DO NOT REPLY [Bug 32425] - jx-macros.xml in java\org\apache\cocoon\forms\generation missing locale variable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32425. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32425 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-02 11:39 --- Fixed by using the default locale in Field.generateItemSAXFragment(), as this problem is not limited to jx-macros.xml. Please cross-check. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [RFC] Cocoon Templates: Name and Tag Interface
Daniel Fagerstrom wrote:
As you probably have noticed, we are working on a replacement on JXTG.
The goal is that it, as far as it is desirable, should be back
compatible with JXTG. But instead of being implemented as a huge (and
somewhat scary) monolith, it will be implemented as a taglib
framework. By implementing it that way it will be much more open for
further development and the goal is to implement taglibs similar to
ESQL etc so that it can work as an XSP replacement as well. It should
be at least as performant as JXTG.
Jonas has submitted an initial implementation based on the design
discussions on the list, that Leszek is going to commit.
---o0o---
We need your input on chosing a name for the framework. And also on
what data that should be available for the taglibs and in what way the
tags should be given access to this data. The design of the tag
interface will be an important question for you when you are going
to implement tags in the future. And it would also be good if we could
agree about the main direction of the tag design quite soon, so that
we can start the development of taglibs in parallel with the framework
development. Please spend some brain cycles on this.
Naming
==
The goal is that the new template framework should replace JXTG and
XSP as the recomended template system for Cocoon users. It is a
community effort rather than a one man show. It is based on our
previous experince of templating solutions.
This should IMO be reflected in the naming. The name should reflect
the intended purpose rather than being a brand name. JX in
JXTemplateGenerator comes from JXPath and as we are going to provide
support for other expression languages as well, JXTG 2.0 would not be
a logical name for the framework IMHO.
I would propose that we (analogous with CForms) refer to it as
template in block name, package name, name spaces and so on. When it
actually delivers what is promised, we can refer to it as Cocoon
Template or CTemplate.
To show that we care about our users previous investments in Cocoon
technology, we can say that JXTG has been re-implemented as a Cocoon
Template tag lib.
Of course other and better naming sugestions are most welcome.
Tag Interface
===
What data should be available for the taglib writer and how should it
be made accessible? What about thread safety?
Expressions
---
This is somewhat OT in the current context but IMO expressions, (the
stuff inside ${}), should only have access to FOM and preferably just
read access. IMHO expressions should not have side effects.
FOM sounds ok, or at least some cocoon object giving access to flow
view data (if any, as it can be used outside of flowscript), request,
session, etc.
Expressions should have no side effects although this is difficult to
enforce strictly as the EL must be able to call a method and we cannot
control what happens within the method.
What Data in Tags?
--
A tag need access to:
* FOM
* The current XMLConsumer for output
* The content of its attributes
* The content of its body (the possibility of executing the body and
geting the result)
+1 The two last items are especially important to implement the CForms
template language (see jx-macros.xml).
The following data is also useful for some tag libs:
* A variable stack for handling local variables in tags or macros
* The tag repository
* The source resolver
That's not needed, as it can be looked up in the ServiceManager.
* The component manager (e.g. for geting a DB connection)
* Its parent tag
* The content of its body (the possiblity to get the body unevaluated)
+1
IMHO tags should behave as if they are side effect free. Side efects
should be performed in flowscripts. From this we can infer that we
only should have read access to the above data. But in practice it
might be hard to enforce and furthermore even if the tag behave as it
is side effect free, it might be better (or the only possiblity) to
implement it in terms of side effects.
Implementation details are discussed in the section Adding Executable
Tags in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110132582421156w=2.
Have I forgotten something or should we remove something?
How to Make Data Accessible in Tags
---
There are two main type of events in the life cycle of a tag: setup
and execution. For a thread safe tag, the setup phase can be divided
in: script compile time setup and execution time setup.
The relation between the tag and the framework has many parallels with
the relation between a component and a component manager, so similar
solutions are possible.
We can have reflection based solution with setter injection of
attributes and possibly the rest of data also. We can have interface
driven injection, (Avalon framework style), where the tag implements
various interfaces for geting the various input data types.
We can also have
Re: [Design] JXTG 2.0 (Just say no!)
Miles Elam wrote: Ummm... Hold on second while I don my flame-resistant underwear. Okay folks, why are we making tag libraries/interfaces *at all*? Take a look at the implementation of JXTemplateGenerator, and the implementation of ESQL and then on the implementations of a couple of the various transformers that interpret different tag languages. Not that pretty. They where certainly not easy to write, they are not easy to read and they are even harder to maintain. Neither the less they do a good work although some of them could need to be updated to reflect our current ideas about how to do things. The main reason to implement tag libs from my POV is to be able to refactor things like JXTG and ESQL as taglibs so that they become easier to support and improve. And so that we can avoid those endless horrendous listings of the methods in the SAX interface as soon as some one want to let a tag doing something. Concerning interfaces for tag libs: they are important as they controll what you can do (and what you are forbidden to do) from you tags. The design of the intefaces will also effect how easy it eill be to write readable tags. I mean it. I feel like a lemming being driven off a cliff. Its just web server code if you avoid using any taglibs in life support system or stearing systems in aeroplanes, your physical safety shoudn't be affected ;) snip/ Why tag libraries? To deal with the excessive code in the markup. No, the reasons are those that I gave above: maintainabillity for those taglibs that we allready have in Cocoon. Then I'm certain that some users are going to do things that I consider ugly and counter productive with the help of taglibs. But people are creative so someone is going to find a missuse for any technology. If you really need code in markup for your corner case, tag libraries aren't going to help the situation much. You need code. So here we stand discussing how to go back to big balls of tag library mud. We are not! From my POV we are going to reimplement the declarative and side effect free parts of JXTG, ESQL, the CForms tags and possibly other _declarative and side effect free_ tags. We have a glimpse of better things with Flow. Sure flow logic, business logic binding and side efects in flowscripts and side effect free presentation oriented stuff in (e.g.) template, clear SoC. Why aren't we examining that model for further direction? Why are we going backwards? Arbitrary Java code executing in the markup but with a prettier face? Great. I'm so happy, I could eat the six month old leftovers rotting in my friend's tupperware. You could spend some of your creativity on finding reasonable contracts on what we want to be able to do in template instead of just ranting. CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart people on this list. C'mon! We are happy if you find and maybe even implement a better idea. Requring others to comme up with smart ideas are like requiring them to implement the features that you need or write the documentation you would like to have: Don't ask your open source community what it can do for you, ask yourself what you can do for your open source community! What have tag libraries been used for? 1. A macro language 2. Data generation 3. Data formatting 4. Backend processing 5. Making programming languages out of markup 6. Data replacement Let's go down the list. 1. A macro language XSLT or any of the other markup transformation syntaxes can handle this. No code or tag API needed. STX: an easy-to-use syntax enabling a SAX stream with a minimal memory footprint. Side effect-free. Highly cacheable. The cached SAX events for JXTemplateGenerator are put in the cache for future use -- same story with a JXTemplateTransformer or any JXTemplate* successor or whatever. Nothing lost by using a simple transformation language. The best part? It's simple. Honestly, have you followed the discussion that my design document was based on? Everyone that ever have tried to fix something in (or tried to understand) JXTG seem to agree about the need of refactoring it, to make it supportable. I have given some suggestions about how to achieve this, better ideas are always welcome. I would prefer to use XSLT or XQuery as a template language, although it doesn't solve how to handle things like ESQL. I spent some effort on doing that one and half year ago http://marc.theaimsgroup.com/?t=10493079564r=1w=2, http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104998241710064w=2, http://marc.theaimsgroup.com/?t=10501653644r=1w=2 and http://marc.theaimsgroup.com/?t=10517844663r=1w=2. But it is quite complicated although possible to make an XSLT or XQuery processor read Java bean structures in an efficient way. Saxon that would be the most attractive choice is MPL 1.0 that was supposed to be incompatible with APL. And then Christopher implemented JXTG which solved
EHDefaultStore
Hi, I needed a cache for part of my webapp. Basically I can look up lists of things, based on a number of parameters. I put all the parameters into a Serializable class which becomes the key. If it isn't in the cache then I create a new object using a stored procedure and add it to the cache. The stored procedure takes about 500ms, hence the need for the cache. I had to create my own version of EHDefaultStore, specific to my app, because I didn't want an eternal cache. I expire items after 5 minutes so that a db hit is forced (in case the data has been updated). Although EHDefaultStore takes many config parameters, it doesn't have eternal, timeToLive or timeToIdle, and is hard coded to always create an eternal cache. My questions: 1) Any reason why those parameters can't be added? Then I could have just configured my own instance in cocoon.xconf with a different role name to the default. 2) EHDefaultStore configures a CacheManager from an xml file, but then creates the Cache object itself using the long Cache() constructor. From my understanding of the EHCache docs, the xml file is used to set the defaults for if a Cache object is created by the CacheManager itself, which isn't being done in EHDefaultStore. We might just as well use CacheManager cacheManager = CacheManager.create(); // or getInstance() even if the values in ehcache.xml are changed, it will make no difference because each Cache is programatically created using specific values for each property. So we don't need it. 3) a CacheManager can manage more than one Cache, yet we create one per instance of EHDefaultStore. OK, at the moment there is only one instance of EHDefaultStore (I think?), but if it's made more generic (see 1) then there could be more. We could have a static CacheManager shared between them all. This does however mean that we'd need an instance count so that the last instance could call cacheManager.shutdown() (and the first client would call create()). But then we already do have an instance count which is used in EHDefaultStore to generate a new name each time the constructor is called. Shall I submit a patch adding any of the above? Jon
Re: review of sitemap component documentation
David Crossley wrote: Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html The next task is to review the table to ensure that all entries have been added for sitemap components. At a glance I can see that Ant generator from scratchpad is missing (org.apache.cocoon.ant.AntBuildGenerator). Regards, P.S. Thanks a lot, this is something that goes a long way towards narrowing the code/doc divide in Cocoon. --- Luca Morandini [EMAIL PROTECTED] http://www.lucamorandini.it ---
Re: [RFC] Cocoon Templates: Name and Tag Interface
Sylvain Wallez wrote: Daniel Fagerstrom wrote: snip/ What Data in Tags? -- A tag need access to: * FOM * The current XMLConsumer for output * The content of its attributes * The content of its body (the possibility of executing the body and geting the result) +1 The two last items are especially important to implement the CForms template language (see jx-macros.xml). The following data is also useful for some tag libs: * A variable stack for handling local variables in tags or macros * The tag repository * The source resolver That's not needed, as it can be looked up in the ServiceManager. You are refering to the source resolver i guess? Maybe the tag repository should be controlled by ServiceManager as well so that included and compiled taglibs are inherited to subsitemaps? Thread Safe or Not? --- Thread safe tags can have better performance as more work can be done during script compile time, but they might be harder to write. What should we chose or should we support both types? I don't see how we can possibly cache precompiled templates if some tag instances are not threadsafe. So IMO *all* tags should be threadsafe. You can put a threadsafe tag factory together with the class name of the thread unsafe tag and possibly other compile time datainto the script. Then the thread unsafe tag is created and instantiated at runtime. Jelly work like that, its certainly has some runtime costs, but it is easier to write the tags. Anyway, I agree with you. We start by requireing the tags to be thread safe and implement the core tag libraries that way. Then we can implement tag adapters for other tag life styles later if we feel that it is needed. If we make the parallel with the TreeProcessor, tags should receive something similar to InvokeContext. This is an object that holds all execution-time data such as the generator's map:parameter, the object model (or maybe not as it's available through the Context) and the variable stack. Sounds good, we have one CompileContext and one InvokeContext. For some tags to be able to store execution-time data, the invocation object should also be able to hold some arbitrary attributes, possibly associated to the tag instance itself. That provides support for both tag-related data (e.g. some data created on start that is needed on end such as SQL connections) or inter-tag communication such as ft:class definitions later used by ft:new tags. Something like: void setAttribute(String name, Object value); Object getAttribute(String name); void setTagAtttribute(Tag tag, String name, Object value); Object getTagAttribute(Tag tag, String name); I had some vauge idea about putting such info in the variable stack. But it might be better to sstore such info so that it is invisible for the EL. Thanks for your comments! /Daniel
DO NOT REPLY [Bug 32491] New: - POST method in cinclude:includexml is broken
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32491 Summary: POST method in cinclude:includexml is broken Product: Cocoon 2 Version: 2.1.6 Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P2 Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Since Cocoon 2.1.6, the cinclude transformer does not handle the POST method correctly. This is easy to see with the example from the Cocoon 2.1 docs: cinclude:includexml cinclude:srchttp://host:port/path/cinclude:src cinclude:configuration cinclude:parameter cinclude:namemethod/cinclude:name cinclude:valuePOST/cinclude:value /cinclude:parameter /cinclude:configuration cinclude:parameters cinclude:parameter cinclude:namemessage/cinclude:name cinclude:valueHi there/cinclude:value /cinclude:parameter /cinclude:parameters /cinclude:includexml In Cocoon 2.1.5 this made a HTTP-POST request, but in 2.1.6 it makes a HTTP-GET request. The code of the CInclude transformer does not seem to have changed. I suspect that this is a bug in the Excalibur SourceResolver, but I can't find where this could be. If someone can make this into a more specific Excalibur bug, please do. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: EHDefaultStore
On 2-dec-04, at 13:13, Jon Evans wrote: Hi, I needed a cache for part of my webapp. Basically I can look up lists of things, based on a number of parameters. I put all the parameters into a Serializable class which becomes the key. If it isn't in the cache then I create a new object using a stored procedure and add it to the cache. The stored procedure takes about 500ms, hence the need for the cache. I had to create my own version of EHDefaultStore, specific to my app, because I didn't want an eternal cache. I expire items after 5 minutes so that a db hit is forced (in case the data has been updated). Although EHDefaultStore takes many config parameters, it doesn't have eternal, timeToLive or timeToIdle, and is hard coded to always create an eternal cache. My questions: 1) Any reason why those parameters can't be added? Then I could have just configured my own instance in cocoon.xconf with a different role name to the default. EHDefaultStore is eternal by design. Having a store that would take care of expiration itself does not fit well with the way Cocoon uses and manages its stores. In order to open up the implementation to other uses than that of Cocoon it would be best to follow the same pattern as DefaultStore is doing. That is, move the current EHDefaultStore to AbstractEHStore and have EHDefaultStore extend AbstractEHStore and hard-code / overide some of the parameter settings. 2) EHDefaultStore configures a CacheManager from an xml file, but then creates the Cache object itself using the long Cache() constructor. From my understanding of the EHCache docs, the xml file is used to set the defaults for if a Cache object is created by the CacheManager itself, which isn't being done in EHDefaultStore. We might just as well use CacheManager cacheManager = CacheManager.create(); // or getInstance() even if the values in ehcache.xml are changed, it will make no difference because each Cache is programatically created using specific values for each property. So we don't need it. Yes, we need it. IIRC some settings can only be specified in the descriptor file. Most notably the filesystem location of the disk-based cache. If you look at the EHDefaultStore code you can see that it relies on the fact that disk based cache location is configured to be the java.io.tmpdir system property. 3) a CacheManager can manage more than one Cache, yet we create one per instance of EHDefaultStore. OK, at the moment there is only one instance of EHDefaultStore (I think?), but if it's made more generic (see 1) then there could be more. We could have a static CacheManager shared between them all. This does however mean that we'd need an instance count so that the last instance could call cacheManager.shutdown() (and the first client would call create()). But then we already do have an instance count which is used in EHDefaultStore to generate a new name each time the constructor is called. Look at the implementation of CacheManager.create(1) the CacheManager is already a shared instance. Calling CacheManager.create() with a different config file after it has already been initialized previously has no effect. Another reason to not have the configuration file be configurable. 1. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107066391625123w=2 -- Unico
Re: EHDefaultStore
Hi Jon, A few loose thoughts here, i just dealt with similar issues last week. Jon Evans wrote: I had to create my own version of EHDefaultStore, specific to my app, because I didn't want an eternal cache. I expire items after 5 minutes so that a db hit is forced (in case the data has been updated). Although EHDefaultStore takes many config parameters, it doesn't have eternal, timeToLive or timeToIdle, and is hard coded to always create an eternal cache. I'm not sure on the exact role of EHDefaultStore (allright I didn't know it even existed). I am using my own cachemanager created as follows CacheManager.create(new FileInputStream(new File( /WEB-INF/classes/ehcache.xml))); In this file i configure my caches and also provide a default cache. I then create my configured caches with manager.getCache(myconfiguredcache1) (a side effect of this is that Cocoon dumps it's ehcache in the dir configured in my ehcache.xml). This means it's using the default cache which is a bad thing IMHO. 2) EHDefaultStore configures a CacheManager from an xml file, but then creates the Cache object itself using the long Cache() constructor. From my understanding of the EHCache docs, the xml file is used to set the defaults for if a Cache object is created by the CacheManager itself, which isn't being done in EHDefaultStore. true, just use the default factory method for creating the cache. 3) a CacheManager can manage more than one Cache, yet we create one per instance of EHDefaultStore. OK, at the moment there is only one instance of EHDefaultStore (I think?), but if it's made more generic (see 1) then there could be more. We could have a static CacheManager shared between them all. This does however mean that we'd need an instance count so that the last instance could call cacheManager.shutdown() (and the first client would call create()). But then we already do have an instance count which is used in EHDefaultStore to generate a new name each time the constructor is called. Doesn't ehcache have finalizer hooks on the cachemanager ? Or is cocoon shutting the cachemanager down properly? Reason i'm asking is that my cache gets shutdown properly even when I don't shutdown the manager. How about making cocoon use an explicit named cache instead of the default one ? Regards, Jorg
Re: EHDefaultStore
On 2-dec-04, at 14:35, Unico Hommes wrote: Look at the implementation of CacheManager.create(1) 1. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107066391625123w=2 Sorry this was not supposed to be related. The above link is an explanation of the current Store pattern in Cocoon. 1 in CacheManager.create(1) is the number of arguments of the method. -- Unico
Re: we are a busy list
Torsten Curdt wrote:
Have a look at Ken's statistics at
http://www.apache.org/~coar/mlists.html
At the bottom there is a top 10 list
of the bussiest list. We have pretty
good ranking IMO :-)
Especially given the fact that commons-dev
combines quite a couple of sub projects.
And especially also considering that it's a dev list!
Sylvain, who just incremented the statistics counter :-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (Just say no!)
Miles Elam wrote:
Ummm... Hold on second while I don my flame-resistant underwear.
snip what=history of template languages/
Why tag libraries? To deal with the excessive code in the markup. If
you really need code in markup for your corner case, tag libraries
aren't going to help the situation much. You need code.
So here we stand discussing how to go back to big balls of tag library
mud. We have a glimpse of better things with Flow. Why aren't we
examining that model for further direction? Why are we going
backwards? Arbitrary Java code executing in the markup but with a
prettier face? Great. I'm so happy, I could eat the six month old
leftovers rotting in my friend's tupperware.
CAN' T WE COME UP WITH A BETTER IDEA!?! There are some really smart
people on this list. C'mon!
What have tag libraries been used for?
1. A macro language
2. Data generation
3. Data formatting
4. Backend processing
5. Making programming languages out of markup
6. Data replacement
Let's go down the list.
1. A macro language
XSLT or any of the other markup transformation syntaxes can handle
this. No code or tag API needed. STX: an easy-to-use syntax enabling
a SAX stream with a minimal memory footprint. Side effect-free.
Highly cacheable. The cached SAX events for JXTemplateGenerator are
put in the cache for future use -- same story with a
JXTemplateTransformer or any JXTemplate* successor or whatever.
Nothing lost by using a simple transformation language. The best
part? It's simple.
2. Data generation
Raise your hands. Let's see who you are that still thinks after all
that we've learned from web development history that
esql:executeSELECT * FROM MYTABLE WHERE COLUMN1 = 0/esql:execute
is a good idea and the best we can come up with? I admit that I was
one of those people that was trying to get a standard relational
database API in Flow. So wrong. SO WRONG. I would like to thank the
developers on this list for their insight and wisdom on this point.
If you are savvy enough to write a Java class that implements the Tag
interface, you are certainly smart enough to write a POJO for use with
Hibernate (or whichever object persistence mechanism you prefer). In
fact, the way things are going and with the tools being made
available, the Tag interface is *harder*. And an implementation of
Tag verses a Javascript object or data structure? The difference in
complexity level isn't even funny.
You miss an important point here: many Cocoon users are not able to
write Java code, and even less a Tag implementation. The purpose of
taglibs and template languages is to provide pre-packaged higher-level
constructs that hide the underlying complexity.
Take a look at ESQL for an extreme example in this area :-)
3. Data formatting
Let's call a spade a spade here. We've got how many variations that
need to be handled?
boolean, integer types, floating point types, dates/timestamps,
strings, XML fragments, selection from limited choices (if 0, say
none -- if 1, say one -- if more, say many), and objects (which
are basically .toString() calls unless it has properties that are
plain old datatypes -- in which case you use the other handlers).
That's what? Seven different formatters? Done. Finished. Do we
really need a tag library for that? Make them reusable components
that transformers can use as needed.
AFAIK, this is exacly the idea: have a set of Formatters (or Convertors)
and share them between template engines, and CForms.
4. Backend processing
We don't like to admit it, but we've all wondered, What if this
custom tag could trigger a cache invalidation or do some workflow
or... Bad idea. Bad idea. Backend processing in your markup
template is a horrible idea. Do it in an action or better yet in Flow.
I partially agree here. When a pipeline is used to produce the view,
i.e. what is sent back to the user, then there should be no side effects.
Now there are times where pipelines are used as part of the application
logic, and is such cases having components with side-effects is allowed.
Such pipelines can be thought of as business logic functions implemented
with pipelines rather than with traditional programming languages.
5. Making programming languages out of markup
foo:if, foo:for-each, foo:eval, etc. Why the foreplay? If
you're gonna write a programming language, at least have the decency
to not base it on markup. These aren't really different from saying
% if (test.isTrue()) { %
foo/
% } %
or XSP's
xsp:logic
if (test.isTrue()) {
foo/
}
/xsp:logic
IMO constructs like this should be context-dependent on the task at
hand. For example, wouldn't it have been easier if instead of
jx:for-each var=person items=${people}
jx:if test=${person.name != 'Mean Mike'}
friend${person.name}/friend
/jx:if
/jx:for-each
you had
friend jx:context=${people} jx:test=${name != 'Mean
Mike'}${name}/friend
Same thing. Not a
jx:attribute
Hi, A while ago [1], there were talks about getting jx:attribute implemented. Has anything come out of this? I have a usecase where i need to write out an arbitrary list of attributes for a tag. Even though these attributes are Nodes i don't see any way of doing this in jx without something similar to xsl:attribute. Or am i missing something here? Regards Jorg [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108222422407397w=2
RE: Possible security problem with flowscript
Hi,
Sorry about reacting to this thread after one month of inactivity, but we
recently switched to a Cocoon version which includes this fix. I have tried
refactoring our application, but it was more work than I expected.
Having an option to turn this behaviour on or off would really make things
easier for me. Our application can run as it is and from the warnings in the
log I can determine what should be changed. Using these warnings I can
gradually make our application compliant with sitemap-bound continuations.
I propose to change the current code in ContinuationsManagerImpl to this code.
As you can see the warnings will always be added to the log as an incentive to
make changes to code which still uses shared continuations:
public WebContinuation lookupWebContinuation(String id, String
interpreterId) {
WebContinuation kont = (WebContinuation) idToWebCont.get(id);
if ( kont != null ) {
boolean interpreterMatches = kont.interpreterMatches(interpreterId);
if (!interpreterMatches getLogger().isWarnEnabled()) {
getLogger().warn(WK: Continuation ( + kont.getId()
+ ) lookup for wrong interpreter. Bound to:
+ kont.getInterpreterId() + , looked up for:
+ interpreterId);
}
return interpreterMatches ||
allowBackwardCompatibleContinuationSharing ? kont : null;
}
return null;
}
'allowBackwardCompatibleContinuationSharing' will be a configuration option
which defaults to 'false'.
If nobody objects I will make the changes, create patches and add a new bug for
this.
Johan Stuyts
Hippo
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Posted At: donderdag 21 oktober 2004 9:49
Posted To: Cocoon Dev List
Conversation: Possible security problem with flowscript
Subject: RE: Possible security problem with flowscript
Leszek Gawron wrote:
Is there any sense to bind continuations to the sitemap? Vadim?
Yes, I really think so. IMHO it is simply wrong to continue
a script
in a sitemap where it hasn't been declared - and as soon as
the flow
script tries to address relative resources it won't work anyway.
Just one more question: should this be an option to maintain
compatibility?
I don't think so, imho it's a bug - in most cases the script breaks
as soon as a pipeline is invoked - or other relative resources are
fetched.
Carsten
Re: Possible security problem with flowscript
Johan Stuyts wrote:
Hi,
Sorry about reacting to this thread after one month of inactivity, but we
recently switched to a Cocoon version which includes this fix. I have tried
refactoring our application, but it was more work than I expected.
Having an option to turn this behaviour on or off would really make things
easier for me. Our application can run as it is and from the warnings in the
log I can determine what should be changed. Using these warnings I can
gradually make our application compliant with sitemap-bound continuations.
I propose to change the current code in ContinuationsManagerImpl to this code. As you can see the warnings will always be added to the log as an incentive to make changes to code which still uses shared continuations:
public WebContinuation lookupWebContinuation(String id, String interpreterId) {
WebContinuation kont = (WebContinuation) idToWebCont.get(id);
if ( kont != null ) {
boolean interpreterMatches = kont.interpreterMatches(interpreterId);
if (!interpreterMatches getLogger().isWarnEnabled()) {
getLogger().warn(WK: Continuation ( + kont.getId()
+ ) lookup for wrong interpreter. Bound to:
+ kont.getInterpreterId() + , looked up for:
+ interpreterId);
}
return interpreterMatches || allowBackwardCompatibleContinuationSharing ? kont : null;
}
return null;
}
'allowBackwardCompatibleContinuationSharing' will be a configuration option
which defaults to 'false'.
If nobody objects I will make the changes, create patches and add a new bug for this.
Fine for me. What I do not like is the
allowBackwardCompatibleContinuationSharing as it indicates that backward
imcompatible change was made while this was a bugfix really.
I will patch the code as soon as you open the issue.
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RFC] Cocoon Templates: Name and Tag Interface
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
snip/
What Data in Tags?
--
A tag need access to:
* FOM
* The current XMLConsumer for output
* The content of its attributes
* The content of its body (the possibility of executing the body and
geting the result)
+1 The two last items are especially important to implement the
CForms template language (see jx-macros.xml).
The following data is also useful for some tag libs:
* A variable stack for handling local variables in tags or macros
* The tag repository
* The source resolver
That's not needed, as it can be looked up in the ServiceManager.
You are refering to the source resolver i guess? Maybe the tag
repository should be controlled by ServiceManager as well so that
included and compiled taglibs are inherited to subsitemaps?
Yes, taglibs should be standard components declared in the service
manager. That way, they are automatically inherited in subsitemaps. What
we need also is a standard set of taglibs that are declared in the
top-level service manager, i.e. cocoon.xconf.
Now about the SourceResolver, it's available in the ServiceManager using
lookup(SourceResolver.ROLE). So it doesn't need to be passed explicitely
as part of the runtime setup.
The fact that generator.setup() has a SourceResolver parameter is
historical, at a time where it wasn't available through the service manager.
Thread Safe or Not?
---
Thread safe tags can have better performance as more work can be
done during script compile time, but they might be harder to write.
What should we chose or should we support both types?
I don't see how we can possibly cache precompiled templates if some
tag instances are not threadsafe. So IMO *all* tags should be
threadsafe.
You can put a threadsafe tag factory together with the class name of
the thread unsafe tag and possibly other compile time datainto the
script. Then the thread unsafe tag is created and instantiated at
runtime. Jelly work like that, its certainly has some runtime costs,
but it is easier to write the tags.
Mmmh...
You then achieve something similar to the CForms architecture where a
form definition is translated into a cached, immutable and threadsafe
FormDefinition object, which acts as a factory for actual Widgets.
This behaviour is needed for CForms as every widget intrinsically have
to hold some state information and therefore are specific to a
particular usage of the form, and that state must persist across
request/response cycles.
Do we need the same for tags? I'm not sure. Thinking further, we don't
even need the per-tag attributes I mentioned below, as a tag
implementation will drive the execution of its children.
Practically, this means that a Tag should have a single execute method
invoked at generation-time, that will do its job and invoke its children
as part of this job. Any tag-related state can then be represented as
local variables.
snip/
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: jx:attribute
I see, so I will have to abandon my jx generator solution then. Is there another generator that can grab a bean from the (session)context and generate tags from it? Can the XSP or JSP generator do this ? Thanks Jorg Leszek Gawron wrote: Jorg Heymans wrote: Hi, A while ago [1], there were talks about getting jx:attribute implemented. Has anything come out of this? I have a usecase where i need to write out an arbitrary list of attributes for a tag. Even though these attributes are Nodes i don't see any way of doing this in jx without something similar to xsl:attribute. Or am i missing something here? Nothing happened. The feature was considered very hard to implement.
Re: [Design] JXTG 2.0 (Just say no!)
Sylvain Wallez wrote:
Miles Elam wrote:
snip/
friend jx:context=${people} jx:test=${name != 'Mean
Mike'}${name}/friend
snip/
Ok. My conclusion about this is twofold:
- taglibgs should be triggered by attributes and not only by elements,
It's ok with me. Question is how do we interprete the construction
above. From commons sense we can infer that the test for the name should
be performed for each person in th sequence of people. We could maybe
infer the same thing by studying the input data structure. What if I
want a double loop over two sets? Any ideas about how to implement it?
What would jx:context and jx:people correspond to? If we just allow one
programatic attribute per element, the code connected to it could be
allowed to do whatever it want to when its parent element is called but
its more complicated when there are several programatic attributes,
how do we control their relative nesting.
snip/
/Daniel
Re: [RFC] Cocoon Templates: Name and Tag Interface
Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: Daniel Fagerstrom wrote: snip/ You are refering to the source resolver i guess? Maybe the tag repository should be controlled by ServiceManager as well so that included and compiled taglibs are inherited to subsitemaps? Yes, taglibs should be standard components declared in the service manager. That way, they are automatically inherited in subsitemaps. What we need also is a standard set of taglibs that are declared in the top-level service manager, i.e. cocoon.xconf. Sounds good. Now about the SourceResolver, it's available in the ServiceManager using lookup(SourceResolver.ROLE). So it doesn't need to be passed explicitely as part of the runtime setup. The fact that generator.setup() has a SourceResolver parameter is historical, at a time where it wasn't available through the service manager. Didn't know that. snip/ You can put a threadsafe tag factory together with the class name of the thread unsafe tag and possibly other compile time datainto the script. Then the thread unsafe tag is created and instantiated at runtime. Jelly work like that, its certainly has some runtime costs, but it is easier to write the tags. Mmmh... You then achieve something similar to the CForms architecture where a form definition is translated into a cached, immutable and threadsafe FormDefinition object, which acts as a factory for actual Widgets. This behaviour is needed for CForms as every widget intrinsically have to hold some state information and therefore are specific to a particular usage of the form, and that state must persist across request/response cycles. Do we need the same for tags? I'm not sure. Don't think we need it either. I'll try to implement a number of tags and see what I think. Thinking further, we don't even need the per-tag attributes I mentioned below, as a tag implementation will drive the execution of its children. Practically, this means that a Tag should have a single execute method invoked at generation-time, that will do its job and invoke its children as part of this job. Any tag-related state can then be represented as local variables. Sounds good. /Daniel
Re: [Design] JXTG 2.0 (Just say no!)
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Miles Elam wrote:
snip/
friend jx:context=${people} jx:test=${name != 'Mean
Mike'}${name}/friend
snip/
Ok. My conclusion about this is twofold:
- taglibgs should be triggered by attributes and not only by elements,
It's ok with me. Question is how do we interprete the construction
above. From commons sense we can infer that the test for the name
should be performed for each person in th sequence of people.
Yes. Actually, it would be clearer if written something like
friend jx:forEach=${people} jx:if=${name != 'Mean
Mike'}${name}/friend
where attributes are actually the same as tag names.
This of course works only for tags having a single attribute.
We could maybe infer the same thing by studying the input data
structure. What if I want a double loop over two sets?
You cannot using tags-as-attributes as there cannot be two attributes
with the same name. In that case, you either use tags-as-elements, or
use some container element.
Any ideas about how to implement it? What would jx:context and
jx:people correspond to? If we just allow one programatic attribute
per element, the code connected to it could be allowed to do whatever
it want to when its parent element is called but its more complicated
when there are several programatic attributes, how do we control
their relative nesting.
IMO, the resolution of tags-as-attributes should follow a priority order
that will be built into the taglib. That can be implemented using a
filter that transforms tags-as-attributes into tags-as-elements in a
predefined order.
There's still a problem however, when tags-as-attributes coming from
several taglibs exist on a single element, as we must know the relative
order of the taglibs.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: review of sitemap component documentation
David Crossley wrote: Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html The next task is to review the table to ensure that all entries have been added for sitemap components. applause/ -- Stefano.
RE: [portal] Need for CachingPortletAdapter
-Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 01, 2004 3:32 PM To: [EMAIL PROTECTED] Subject: Re: [portal] Need for CachingPortletAdapter URDINA Michal wrote: Hi, currently provided PortletAdapter does not offer caching ability for JSR168 portlets. I really need caching for portlets and I wanted to implement this feature as new CachingPortletAdapter. Having looked at URICopletAdapter and CachingURICopletAdapter the caching implmentation for coplets is pretty simple. CachingURICopletAdapter relies on these principles: - coplet content is XML - coplet content it is cached/emited in the generator of portal generating pipeline - links are cached untranslated and the link translation occurs in the transformer that follows generator PortletAdapter relies on these principles: - portlet content is not XML (however it is often XHTML) - portlet content is emited in serializer of portal generating pipeline - links are translated in the portlet generation and are part of portlet content Main issue I see in implementing CachingPortletAdapter is link translation. 1.) links that are sent to browser are valid only for the next request 2.) translated links are part of generated content 3.) portlet content cannot be cached since its links will not be valid after next request If you use PageLabels the above is not true. Events are valid until they are regenerated on the next request to that page label. Has anyone been thinking about the caching of content for JSR168 portlets? I would be happy if we could come to common solution that could be consequently implemented. No, I haven't been thinking of it, but it seems like it would be a good thing. I'd welcome a proposal and/or code. Michal Ralph Thanx! Your PageLabels seem like great enhancement to the portal engine. Need to look closer but seems like caching of portlet content will be breeze with pagelinks in use. But there is one issue remaining. I am afraid that links don't work on first portal page in samples. Seems like pagelinks won't work on pages with no tabs. Did you encounter same behaviour? Michal
Re: [Design] JXTG 2.0 (Just say no!)
Daniel Fagerstrom wrote: Miles Elam wrote: [a little too emotional fight that brings the danger of moving the important points discussed on the bottom and the rants at the top, hiding the signal] A little story first. I'm writing a thing called Dynagump these days. It's a web application and it's supposed to do reports out of a database that gump populates every night. It's supposed to replace the static web pages that gump generates today and that don't keep historical information. Concerned by bootstrappability, I tried with Python stuff and found out that Python is literarely 5 years behind in web technologies. They are all thinking that CGI-BIN is good enough (example, MoinMoin) or, if not, they build their own web server (example, Zope). Some people had the brilliant idea to write Servlets for Python (d'oh!) in a thing called WebKit. Pretty cool. It feels like JServ 0.9.11. 7 years ago would have been a compliment. So I decided I didn't want to spend 3 years of my life to rewrite (one more time!) the history of servlets in python and I switched back to java. Also, I tried to be as simple as possible: velocity templates and a resultset as a bean. It turns out that velocity iterates only on iterators and resultset don't implement iterators. So, either I write my own iterators or I do something else. Since I never used it, I tried Hibernate. Took me a few hours, but I had it: I was able to show my projects on a web page. Uhuh!! Ok, now, let's write a real userful page. Hmmm, well, oh, yeah, URL management... web.xml... crap. One servlet and all as parameters? nah, too 90's. one servlet that does URL management? all right. so I start writing what turns out to look like a sitemap-like URL matching system. nono, stop that. back to the templates. h, all right, I know I have to display the results of SELECT builds.id, builds.result, builds.start_time, project_versions.project, results.name FROM builds, project_versions, results WHERE builds.run = $ID AND builds.project_version = project_versions.id AND builds.result = results.id ORDER BY builds.start_time ASC but how in hell is this translated into O/R mappings? I look around and it seems that I have to do the whole joins by myself... Wait a second! This is a publishing application. No roundtripping. Multichanneled. URL-space problems, SQL describing the data results perfectly. Screw that, I'm using cocoon. Thanks to SVN, I moved the hibernate version somewhere else and started over with cocoon. First, I tried to do the same thing that I did with velocity+hibernate in cocoon if I wanted to use velocity, I needed to have a way to invoque the controller... but I didn't have state to manage, so why should I use flowscript for that? I tried with a simpler SQLTransformer. Worked fine, but then, I thought... well, sometimes, the queries change depending on the request parameters h, so, how do I do that in SQLTransformer? an XSLT stage between the generator and the transformer? nah, gross. All right, let's use XSP. - o - Now I find myself in this weird limbo. One side of me still likes XSP. The syntax is ugly since XML and Java don't mix that well (and it will be even worse with 1.5 generics!), but the power is incredible. If you know what you are doing it's like writing servlets at 100x the speed but without all the crap that JSP forces you since you don't have a pipeline after you. The only taglibs I'm using are ESQL and request. I do the if/then/else in java code. It works just fine, but I'm afraid that this will stop non-xsp-users from being able to contribute to my effort once it starts and this scares me. So, my other side thinks that having a scripted controller invoquing different templated views is a better solution. In this case, do we need taglibs at all? no we don't. esql:queryselect * from blah/esql:query sounds easy enough, but in real life it's more something like esql:connection esql:poolgump/esql:pool esql:execute-query esql:query SELECT name,description FROM projects ORDER BY name /esql:query esql:results esql:row-results li axsp:attribute name=hrefprojects?name=esql:get-string column=name//xsp:attributeesql:get-string column=name//a - esql:get-string column=description/ /li /esql:row-results /esql:results /esql:execute-query /esql:connection and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!! What I want is something like this: - request comes - sitemap gets it - matcher matches - controller is executed and populates beans in the request context - pipeline is invoqued with access to the request context - response goes Now, this can happen right now in flow and JXtemplate. If we don't need state management, this is just like having a better action model with XSP-like
Re: [CForms] How to iterate other a model?
Hi, after I had tried several times to iterate over a widget using flowscript (model.lookupWidget()) I had realized that - in my opinion - this is not easily possible. The problem: I don't know the id's of the widgets! So there are two big questions I'm having: 1) In Java I can use .getChilds() of a ContainerWidget which returns me an iterator to iterate over all childs of an widget. I couldn't find such a method in the flowscript API. How to solve this problem? Either I need a length of all childs and then I can get one by one by pointing to its index or I need an iterator. 2.) I didn't find a way to resolve a Widget value of type MultiValueField. Therefore its not possible to retrieve such values. None of typeof or instanceof worked correctly to determine the object type. How can I resolve whether it is a MultiValueField or not? Thanks! Regards Stephan
Re: [Design] JXTG 2.0 (Just say no!)
Sylvain Wallez wrote: You miss an important point here: many Cocoon users are not able to write Java code, and even less a Tag implementation. The purpose of taglibs and template languages is to provide pre-packaged higher-level constructs that hide the underlying complexity. I'm sorry but I can't take this argument any longer. Programming is not just learning a syntax, but it's the mapping of a mental model. Mental model that people that write templates simple *DO NOT* have, nor care to have. Take a look at ESQL for an extreme example in this area :-) In a perfect world, templates wouldn't need conditionals and iterations, they would come streight out of photoshop, pixel-perfect and flexible at the same time. Too bad that doesn't apply. So there is somebody that does the skeleton layout, somebody that does the photoshop prettyfication, and somebody that populates the data the pages need and somebody that mounts the pieces together. Sometimes, depending on their skills and time availability, a person does more than one of the above tasks. But it's expremely rare (and, by consequence, expensive!) that a single person is able to do all 4 and excel at it. We are subscribed here because we understand the above perfectly and that's why we believe in framework-enforced SoC. Now, let's apply that reasoning to the current discussion and let's make the following, very simple, stateless yet dynamic page: a page that shows the names and ages of the current employees as a table and has the ability to order them by name or by age. The database model is name, birth-date. Now, let's take the above situation and write the taglibs that are general enough and simple enough for the people doing the HTML layout to understand. Now let's analyze what the above would mean in terms of SoC: 1) the order type has to be passed to the page, either as a request parameter or as a URL type. In the first case, the sitemap doesn't have to be touched, in the second it does, but pages need to be duplicates, so the template designers will prefer the first. 2) the database model does not contain the age, so that needs to be calculated from the database results 3) the ordering is done either at the database level, or at the page level. in either case, there must be a conditional between the different type of orderings 4) the results need to be iterated, since their number is not known. Now there are two approaches: 1) model 1: taglibs 2) model 2: controller + view Model 1 removes all the underlying machinery but leaves the glueing to the one that does the template design, or forces two people to work on the same file (which is bad). Model 2 removes both the underlying machinery and the gluing (request - order, birth-date - age) and leaves the template designer with iteration. So, result: Model 2 is a clear winner in terms of SoC analysis, no matter what interfaces the taglibs exhibit, no matter what syntax the templates or the controller have. Why? because Model 1 removes the machinery but leaves the programmatic glueing (which template designers' mindset don't contemplate). Model 2 does not. Result: taglibs are to be considered harmful, no matter what syntax. -- Stefano.
RE: [portal] Need for CachingPortletAdapter
Thanx! Your PageLabels seem like great enhancement to the portal engine. Need to look closer but seems like caching of portlet content will be breeze with pagelinks in use. But there is one issue remaining. I am afraid that links don't work on first portal page in samples. Seems like pagelinks won't work on pages with no tabs. Did you encounter same behaviour? Yes. I suppose that is by design. PageLabels are only generated for named items, primarily because items don't have any information to use to generate a page label. If you have an idea on how that could be improved I'd certainly be open to it, although I'm a little unclear on why not having a page label on a single page web site would be a problem. Maybe you could provide an example that would illustrate that. Ralph
Re: [Design] JXTG 2.0 (Just say no!)
On Thu, Dec 02, 2004 at 01:27:09PM -0500, Stefano Mazzocchi wrote: Sylvain Wallez wrote: You miss an important point here: many Cocoon users are not able to write Java code, and even less a Tag implementation. The purpose of taglibs and template languages is to provide pre-packaged higher-level constructs that hide the underlying complexity. I'm sorry but I can't take this argument any longer. Programming is not just learning a syntax, but it's the mapping of a mental model. Mental model that people that write templates simple *DO NOT* have, nor care to have. Thank you, Stefano, for emphasizing the split between the mental model of the programmer versus that of the template designer. I would like to now accentuate another aspect of our problem and solution space. Babel-Driven Separation of Concerns (BDSoC) versus Graduated Complexity Separation of Concerns (GCSoC) We are currently using Babel (different languages) to enforce separation of concerns, and this has its merits, in that it creates a high barrior between different concerns, but also carries an obvious price. Another (complementary?) route would be to separate concerns via Graduated Complexity (same languages, with different levels of feature-sets available.) This would at least allow the people assigned to the different concerns to talk the same languages, with just the specific vocabularies varying. For example, picture a generic tag engine with sets of tag libraries. Configure one instance of the tag engine, giving it access to only the programming tags (such as to duplicate ESQL functionality.) Configure another instance of the (same) tag engine with access to only the templating tags. The framework development community now is in the easier position of supporting one instead of two languages, while the separation of concerns is still enforced upon the framework users. A side effect in this example is that the programmers and template makers gain a common base language, possibly making their needs easier to express to each other, maybe even leading to cross-pollination between their skillsets, allowing them to work more smoothly together while working on their respective concerns. WDYT? --Tim Larson
Re: [Design] JXTG 2.0 (Just say no!)
Stefano Mazzocchi wrote: snip/ What I want is something like this: - request comes - sitemap gets it - matcher matches - controller is executed and populates beans in the request context - pipeline is invoqued with access to the request context - response goes Now, this can happen right now in flow and JXtemplate. If we don't need state management, this is just like having a better action model with XSP-like code recompilation. But the whole point of this discussion is: do we need taglibs? I'm sorry, but I agree with Miles, we don't: all we need is a velocity/garbage-like template system and recompilable java controllers. Everything else is making a step backwards. Stefano, for those that skipped taglibs in their path to Cocoon (e.g me!), can you explain what you don't like about them? I presume you're okay with a jxtemplate like syntax, but what you don't like is the fact that I can write my own taglib, thus hiding logic not in my controller, but in a taglib class somewhere. Is that it? Presumably, you wouldn't also be against, for example, implementing the FormsTransformer as a part of a templating system? i.e. having the template put the widget values straight into the SAX stream. Have I understood, or are you getting at something else? Regards, Upayavira
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a well
working way of creating views, but that the implementation is very hard
to maintain.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a week
ago or so.
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
So we need a template generator with three sets of tags jx:, esql:
and ft: thats it.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
--- o0o ---
Given these general requirements that have been discussed again and
again at the list and also some more technical, performance driven
requirments, I steped forward and proposed a possible way of
implementing it. This design is based on a rather far going SoC in the
interest of keeping it maintainable. We have also identified a number of
templateing components that are needed in other places in Cocoon. E.g.
expression language and object model and therefore are worth
implementing as separate components. I also proposed implementing the
three sets of tags discussed above as taglibs instead of making their
interpretation being part of a huge monolitic SAX event handler as in
JXTG. Implementing it that way it is must easier to write test code for
the tags and generally easier to understand what is going on.
--- o0o ---
Given this background, I was quite suprised when Miles Elam whent
ballistic about that I mentioned the word taglib and draw conclsions
about my intensions that are far and in several cases oposite from what
I feel and have written anything about.
Anyway, if you have better suggestions about how to solve the above
requirements I'm all ears.
--- o0o ---
Now over to commenting what you have written.
So, my other side thinks that having a scripted controller invoquing
different templated views is a better solution.
In this case, do we need taglibs at all? no we don't. esql:queryselect
* from blah/esql:query sounds easy enough, but in real life it's more
something like
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects ORDER BY name
/esql:query
esql:results
esql:row-results
li
axsp:attribute
name=hrefprojects?name=esql:get-string
column=name//xsp:attributeesql:get-string column=name//a -
esql:get-string column=description/
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple standardized
XML serialization of the row set and then transform it to HTML in XSLT.
The only difference compared to the SQLTransformer would be that I can
combine it with JXTG constructions and insert query params in a
convinient way.
If I would like to do everything in one step as you suggest above it
might look more like:
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects WHERE
projectleader=${cocoon.request-param.id}ORDER BY name
/esql:query
esql:results
esql:row-results
li
a href=projects?name=${$row.name}/${$row.name}/a -
${$row.description}
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
As we are using the same kind of expression template mechanisms as in
JXTG. We could probably make the syntax more efficient and take away
some of the tag layers if we feel like that.
What I want is something like this:
- request comes
- sitemap gets it
- matcher matches
- controller is executed and populates beans in the request context
- pipeline is invoqued with access to the request context
- response goes
Now, this can happen right now in flow and JXtemplate. If we don't need
state management, this is just like having a better action model with
XSP-like code recompilation.
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
Everything else is making a step backwards.
As said above my only purpose
RE: jx:attribute
Maybe this is too simple but what if you iterate over the bean properties
and generate your own xml version with tags, which is then transformed by an
XSL sheet to what you want?
jx:foreach item ...whatever
mytag${item}/mytag
/jx:foreach
HTH.
Bye, Helma
-Original Message-
From: Jorg Heymans [mailto:[EMAIL PROTECTED]
Sent: Thursday, 02 December 2004 16:41
To: [EMAIL PROTECTED]
Subject: Re: jx:attribute
I see, so I will have to abandon my jx generator solution
then. Is there
another generator that can grab a bean from the (session)context and
generate tags from it?
Can the XSP or JSP generator do this ?
Thanks
Jorg
Leszek Gawron wrote:
Jorg Heymans wrote:
Hi,
A while ago [1], there were talks about getting jx:attribute
implemented. Has anything come out of this?
I have a usecase where i need to write out an arbitrary list of
attributes for a tag. Even though these attributes are
Nodes i don't
see any way of doing this in jx without something similar to
xsl:attribute.
Or am i missing something here?
Nothing happened. The feature was considered very hard to implement.
cocoon-2.1.x-dev\site not found
I've just tried ./build.sh clean docs After building cocoon, it said: forrest.checkhome: forrest.home.present=true build.properties.present=true docs: Created dir: D:\documents\cocoon\cocoon-2.1.x\build\cocoon-2.1.7-dev\docs BUILD FAILED D:\documents\cocoon\cocoon-2.1.x\tools\targets\docs-build.xml:105: D:\documents\ cocoon\cocoon-2.1.x\build\cocoon-2.1.7-dev\site not found. Total time: 1 minute 53 seconds Any ideas what's up? Regards, Upayavira
Re: [Design] JXTG 2.0 (Just say no!)
Stefano Mazzocchi wrote: snip/ Now there are two approaches: 1) model 1: taglibs 2) model 2: controller + view 3) model 3: taglibs + view Model 1 removes all the underlying machinery but leaves the glueing to the one that does the template design, or forces two people to work on the same file (which is bad). Model 2 removes both the underlying machinery and the gluing (request - order, birth-date - age) and leaves the template designer with iteration. We always use the 3:rd model. The first taglibs part contains the same stuff as you put in the controller but it is written by people who are skilled in SQL but they are in most cases not programmers. The view is written in XSLT, it might be designed by a designer in Dreamweaver, but then a developer typically embed it in XSLT so that we can use the same design for many pages. So, result: Model 2 is a clear winner in terms of SoC analysis, no matter what interfaces the taglibs exhibit, no matter what syntax the templates or the controller have. Why? because Model 1 removes the machinery but leaves the programmatic glueing (which template designers' mindset don't contemplate). Model 2 does not. Result: taglibs are to be considered harmful, no matter what syntax. Come on, with such comparisons you can prove anything. Don't you remember that you based Cocoon on xml-pipelines any more? /Daniel
Re: [Design] JXTG 2.0 (Just say yes!)
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a well
working way of creating views, but that the implementation is very hard
to maintain.
Fair enough. A template language has nothing to do with taglibs, per se.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a week
ago or so.
After using it for a little while, I changed my mind. :-)
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
I believe the best template system does not use tags at all. It either
uses content (as in velocity) or it uses attributes (as in tapestry).
So we need a template generator with three sets of tags jx:, esql:
and ft: thats it.
I disagree, we don't need a set of tags *AT ALL*.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
--- o0o ---
Given these general requirements that have been discussed again and
again at the list and also some more technical, performance driven
requirments, I steped forward and proposed a possible way of
implementing it. This design is based on a rather far going SoC in the
interest of keeping it maintainable. We have also identified a number of
templateing components that are needed in other places in Cocoon. E.g.
expression language and object model and therefore are worth
implementing as separate components. I also proposed implementing the
three sets of tags discussed above as taglibs instead of making their
interpretation being part of a huge monolitic SAX event handler as in
JXTG. Implementing it that way it is must easier to write test code for
the tags and generally easier to understand what is going on.
Very well, you just picked the wrong name: a refactoring of common
services into reusable components has nothing to do with enforcing the
use of tags into a template language.
But more on this later.
--- o0o ---
Given this background, I was quite suprised when Miles Elam whent
ballistic about that I mentioned the word taglib and draw conclsions
about my intensions that are far and in several cases oposite from what
I feel and have written anything about.
keep reading and you might understand why.
Anyway, if you have better suggestions about how to solve the above
requirements I'm all ears.
Here I am.
--- o0o ---
Now over to commenting what you have written.
Bring it on :-)
So, my other side thinks that having a scripted controller invoquing
different templated views is a better solution.
In this case, do we need taglibs at all? no we don't.
esql:queryselect * from blah/esql:query sounds easy enough, but in
real life it's more something like
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects ORDER BY name
/esql:query
esql:results
esql:row-results
li
axsp:attribute
name=hrefprojects?name=esql:get-string
column=name//xsp:attributeesql:get-string column=name//a -
esql:get-string column=description/
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
and *THIS IS THE SIMPLES QUERY I CAN THINK OF*!!!
In the general case I would rather write just the query with some
surrounding tags like in the SQLTransformer, get a simple standardized
XML serialization of the row set and then transform it to HTML in XSLT.
That works only for trivial monolythic cases. For any serious reporting
application (for example, where order is parameter dependable) that
doesn't work.
The only difference compared to the SQLTransformer would be that I can
combine it with JXTG constructions and insert query params in a
convinient way.
This is exactly the point that makes me say just say no to taglibs
because, as I explained before, no matter what syntax, putting query
parameters in a SQL string is not something that should be in a template!
If I would like to do everything in one step as you suggest above it
might look more like:
esql:connection
esql:poolgump/esql:pool
esql:execute-query
esql:query
SELECT name,description FROM projects WHERE
projectleader=${cocoon.request-param.id}ORDER BY name
/esql:query
esql:results
esql:row-results
li
a href=projects?name=${$row.name}/${$row.name}/a -
${$row.description}
/li
/esql:row-results
/esql:results
/esql:execute-query
/esql:connection
As we are using the same kind of expression template mechanisms as in
JXTG. We could probably make the syntax more efficient and take away
some
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote:
One concern is to come up with a unified template language. This implies:
1) understanding the features we want (and we don't want!) from a
template language
2) come up with a syntax
3) implement it
Another and completely separate concern is how to factor out existing
bits so that #3 is easier.
You are attacking #3 before attacking #1 and #2 and that's why everybody
here is feeling frustration: there is no consensus on #1
I don't think so. There were tons of mails and IMHO we agreed on a list of
features (maybe a final summary is missing)
and #2 so
IIRC we aggreed that we like the current syntax of JXTemplate. Exception: We
deprecate the #{} notation in favour of ${xpath:}.
attacking #3 now is more harmful than useful.
hmmm, IMO #1 and #2 was done ...
--
Reinhard
Re: [Design] JXTG 2.0 (Just say you're sorry!)
First of all, I would like to apologize for my inflammatory tone. My
ire was directed toward the proposal, not the people proposing it.
That said, I went over the top. Too many arguments with young Earth
Creationists lately and it spilled over into my writing on this list.
To Leszek in particular, I am sorry for the reckless criticism. To
Stefano, I'm sorry for putting you in the position of agreeing with
someone who did not conduct himself well.
But I have seen taglibs go terribly wrong in real-world situations far
more often than they've worked out. I'm a firm believer in defining
the interface first through use cases and only afterward discussing the
implementation/design. Granted, my primary experience with taglibs is
JSP's flavor. That may have colored my view of the technology unfairly
in general.
On Dec 2, 2004, at 12:54 PM, Daniel Fagerstrom wrote:
Let me re-iterate: there have for a long time been a concesus at the
list among those who have cared enough to discuss it that JXTG is a
well working way of creating views, but that the implementation is
very hard to maintain.
Granted, but citing that JXTG is a monolithic headache doesn't mean
that the deconstruction must be total. Modularization can happen in
degrees. For example, just by making a common interface between lookup
libraries (JXPath, JEXL, etc.) would remove HUGE amounts of code from
JXTG. The switch back and forth between object lookup mechanisms is
probably the biggest reason for JXTG's complexity.
In addition, I've had virtual sitemap component possibilities floating
through my head lately. Having a generator like:
map:generator name=example
map:absolutize param=templatename/
map:generate type=file src={templatename}.xml/
map:transform type=stx src=macros.stx/
map:transform type=datainject/!-- Yes, I know this doesn't exist
now --
/map:generator
This strikes me as doing very much what is expected from taglibs. The
advantages I see are that (a) it's easier for a site administrator to
see at a glance what goes on and (b) keeps things sane from an
implementation standpoint. What do I mean by 'b'? From my experiences
with JSP taglibs, any taglib must either be absolutely self-contained
or fundamentally aware of all other taglibs in use. Mixing them in the
same document blows some assumptions about use out the window in
certain cases. Debugging and reworking them ends up being
fundamentally similar to writing raw code.
Other than for the purposes of mixing logic from different sources
simultaneously and praying they cause no mutual compatibility/state
problems, I don't see the advantage over transformers. In addition, if
attributes were trigger items (attrlibs?), what determines precedence
when there are two different attrlibs at work?
foo data:bar=action; macro:bar=action/
XML parsers are under no obligation to enforce the document order of
attributes. What happens either way? Does data injection happen first
or macro expansion? What if the element is dynamically renamed or
conditional? On the other hand, if you predetermine precedence, what
advantage is there over transformers? Remember, tag apis are no less
code than transformer code. Programming is programming. Only the API
varies.
There has also been an agreement about that ESQL is the only reason
(besides back compability) to care about XSP, you said so youself a
week ago or so.
But is ESQL is the best choice? Data input becomes a big deal when you
use ESQL for output and then a stream generator combined with
transformation combined with sqltransformer combined with...
I'm a big proponent of make the better decision easier than the worse
decision. Quick and dirty, ESQL works. For limited obscure cases,
ESQL is great. But the better decision would be to use object mapping
(Hibernate, JDO, et al.) and CForms in Flow. Tag libraries seem to me
to promote an excessive shift of logic to the templating language
instead of in the backend data processing architecture. Not forcing
but encouraging people to move as much logic as possible to Flow seems
like it would allow more flexibility while remaining more maintainable
and clear. Clear not in the sense that the individual template and
app is understandable but that the hundredth template and app is
understandable.
For those of us who use CForms it is very convenient to be able to use
the template tags together with JXTG constructs.
So we need a template generator with three sets of tags jx:, esql:
and ft: thats it.
We also discused how to use a separate conversion layer to remove the
need for formating constructs from the template layer.
I'm not following. If you are using CForms (and thus Flow), why would
you make template calls to a database? Why not do the persistence
logic in Flow right next to where you are sending and receiving form
data? From a logical point of view, I would think that these would be
better served
Deploying cocoon on WebLogic8.1
Title: Message Hi, I deployed cocoon on WebLogic 8.1 as a exploded war. I was unable to view the welcome page when I tried http://localhost:8001/cocoon. I had to modify the main pipeline in sitemap.xmap from map:match pattern="" to map:match pattern="index.html" I had to do similar changes to other pipelines. Wondering, if these changes can be done checked in cocoon. To make sure thatthese changes work on all app server, we need to add following welcome-file-list to web.xml: welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list Your comments??? Thanks, Kiran
DO NOT REPLY [Bug 28724] - FragmentExtractor always returns same fragment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28724.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28724
--- Additional Comments From [EMAIL PROTECTED] 2004-12-03 00:10 ---
Try using this code instead:
org.apache.cocoon.environment.Request request =
ObjectModelHelper.getRequest(objectModel);
String queryString = ;
java.util.Enumeration names = request.getParameterNames();
java.util.TreeSet sortedNames = new java.util.TreeSet();
while (names.hasMoreElements()) {
sortedNames.add((String)names.nextElement());
}
java.util.Iterator namesList = sortedNames.iterator();
String name;
String[] parameters;
while (namesList.hasNext()) {
name = (String)(namesList.next());
parameters = request.getParameterValues(name);
java.util.Arrays.sort(parameters);
for (int index = 0; index parameters.length; index++) {
queryString += name + = + parameters[index] + ;
}
}
this.requestURI = ObjectModelHelper.getRequest(objectModel).getSitemapURI
()
+ ? + queryString;
This will include all parameters from either a POST or a GET. It also sorts
the parameters by alphabetical order so it doesn't matter which order they are
sent in.
I have been giving some thought to the caching issue. The assumption with
caching is that if the cache keys are the same the output will be the same.
The FragmentExtractorTransformer will always extract the same fragments for a
given output, ie it is not dependant on the input parameters. Therefore a
timebased fragment id would be sufficient. This is because it is really up to
the other components, especially the one that generated the fragments to be
extracted, to determine the cache key depending on their inputs. If they
produce the same cache key then the cached result will be returned (with the
previous fragment id) and FragmentExtractorTransformer will not be called.
Try changing the line in endElement from:
String id = Long.toHexString((hashCode()^HashUtil.hash(requestURI)) +
fragmentID);
to:
String id = Long.toHexString(System.currentTimeMillis()) + fragmentId;
and remove the code I suggested at the start.
This will also cover time dependent data because it shouldn't be generated in a
caching pipeline anyway.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
Re: [Design] JXTG 2.0 (Just say you're sorry!)
snip type=a very interesting discussion/ ..now let me chime in Having spent quite some time with XSP and ESQL (and friends) I have to admit: XSP can become a PITA. But usually because of taglibs (...as already mentioned in the thread) The very basic XSP is not much more but using java as your templating language. Well, the thing is java and XML just don't mix very well. ...but that's just a question of the syntax. Yes... I do think that taglibs are the evil of XSP. The compilation part ...not nice but more or less depends on how you deal with it. The good and the bad is that XSP gives the full power of java. ...full access to every- thing available in the jvm. But is ESQL is the best choice? Data input becomes a big deal when you use ESQL for output and then a stream generator combined with transformation combined with sqltransformer combined with... I'm a big proponent of make the better decision easier than the worse decision. Quick and dirty, ESQL works. For limited obscure cases, ESQL is great. Hm... I am wondering what you mean by the big deal of the input. Fact is that ESQL has some very unique features. ..that are needed in not so obscure cases. I might not be up-to-date with object mapping frameworks but even if you say that they all support query time row limitations ...so tables of a million+ rows are still page-able without having the data shuffled across the network by the stupid JDBC driver implementation ...there still is the question if *you* do the database design. Mapping to a bad designed database can be also be no big fun. Anyway what I was trying to say ...sometimes SQL can be a very concise syntax for what your framework might make even more complicated. Sometimes... ...it just depends! I think a much bigger problem of ESQL (and also the SQLTransformer) is the time when the database processing is happening. ...just too late. Inside the view ...to bring the MVC up again. It should better be inside the controller. Which would be most likely flow. But noone wants to pollute the flow with SQL statements (does someone)? ...that's the real beauty of flow with a relational mapping IMHO. my 2 cents -- Torsten
Cocoon FirstFriday is today
A reminder that Cocoon FirstFriday starts in 9 hours. http://wiki.apache.org/cocoon/FirstFriday
Re: [Design] JXTG 2.0 (Just say yes!)
Stefano Mazzocchi wrote:
The only difference compared to the SQLTransformer would be that I
can combine it with JXTG constructions and insert query params in a
convinient way.
This is exactly the point that makes me say just say no to taglibs
because, as I explained before, no matter what syntax, putting query
parameters in a SQL string is not something that should be in a template!
Thank you.
Sure, that's a better syntax, but the fundamental problem remains:
template designers don't know nothing about SQL, nor care, nor know
anything about request parameters, not know anything about dynamic
tags nor know how to debug something in case somebody screws up with
the order of those tags!
let me rewrite the above:
controller.script:
var query = SELECT name,description +
FROM projects +
WHERE project= + request.id +
ORDER BY name ;
var results = cocoon.datasources.gump.execute(query);
request.context.set(projects,results);
view.template (content style):
ul
#foreach project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
#end
/ul
or view.template (attribute style):
ul x:foreach=project in projects
lia href=projects?name=${project.name}${project.name}/a -
${project.description}/li
/ul
note how SoC also allows you to use a different technology (example,
O/R or straight OODBMS or even RDF triple stores!) to populate the
beans without the template designers know anything about this!
Thank you! If this isn't a case study of what to do with simple
queries, I don't know what is.
Personally I like:
ul x:test=projects
li x:context=projectsa href=projects?name=${name}${name}/a -
${description}/li
/ul
Where each item in projects becomes the reference scope. ;-) If there
are no projects, no list tags are written. But then, I'm one of those
weird guys who doesn't mind seeing things like ${.} occasionally to
refer to the current iterated item. I also have to admit a love for
test conditionals that don't require the explicit != null grammar.
Hey! We can all dream, right?
One concern though: Is that results variable a result set or just a
collection of data. If the former, how is the database connection
handled (closing or returning to the pool)? If the latter, how can
large result sets be returned without exhausting memory from a few
queries? That's the one case where I see ESQL winning out. All other
cases where you aren't dumping the contents of a table, this seems like
an excellent idea. If a web developer can't handle that much scripting,
what chance do they have with an ESQL taglib?
Sure, I agree with all that. Only question is: where do I put my SQL
queries in the above scenario?
this is the whole stinking point: *never* in the template!
Thank you.
But the whole point of this discussion is: do we need taglibs?
I'm sorry, but I agree with Miles, we don't: all we need is a
velocity/garbage-like template system and recompilable java
controllers.
If you by this mean that you don't see any need in writing special
purpose taglibs as a typical part of normal webapp development, I
couldn't agree more.
No, not only that: I think that the person responsible for doing
writing the logic that drives the flow *and* the content population of
the page is *NOT* the same person that does the design of the template.
Thank you.
- Miles Elam
RE: [Design] JXTG 2.0 (Just say yes!)
Miles wrote: One concern though: Is that results variable a result set or just a collection of data. If the former, how is the database connection handled (closing or returning to the pool)? If the latter, how can large result sets be returned without exhausting memory from a few queries? That's the one case where I see ESQL winning out. Surely the controller script should handle this too? After calling the template it should clean up the model.
Re: [Design] JXTG 2.0 (Just say yes!)
On Thu, 2004-12-02 at 16:47 -0500, Stefano Mazzocchi wrote:
snip...
In both cases, they are suboptimal from what I wrote above, where
content population and content presentation are kept completely isolated
and the only contract between the two is:
1) the shape of the objects in the context
2) how to perform simple variable espansion, list iteration and
conditioning.
#2 is the only thing that should be exposed to a template language (just
like velocity does), everything else should be dealt with at the view
population level. Which is going to be code, written by coders and
people that deal a lot better with code than with anything else.
I think the reason for taglibs are that rendering an object is often
more complicated than simply outputting a value. For example, suppose
you want to render a calendar covering the current month. This is a
typical component that would lend itself well as a tag class. The
template writer would simply do:
calendar:month current-date=${myDate}/
The tag might output something like this:
month value=2
week value=12
day value=5 name=Monday/
day value=6 name=Tuesday current=true/
day value=7 name=Wednesday/
...
/week
...
/month
Later transformations would transform it into a table or whatever. This
type of calendar would be very hard to do for a template author without
the help of a tag library.
The current discussion about taglibs have focused very much on esql and
whether SQL belongs in templates or not. I agree that SQL in templates
are a bad idea, but that is really beside the point in regards to the
virtues of taglibs. Taglibs (in my view) are primarily about converting
objects to SAX. Here are a few ideas for taglibs that only deals with
presentation of objects (as opposed to esql which also populates).
* Bean renderers
* DOM renderers
* ResultSet renderers (ie renders a query made in flow)
* Menus
* Page navigation
* Tabs (similar to tabs in CForm)
* CForm tags
* cinclude
* Calendars (showing week, month etc.)
The items above are in my view better examples of the benefits of
taglibs. They're all about how to render an object. The object is
populated in flow but how to render it is implemented in the tag
classes.
Cheers Jonas
Re: [Design] JXTG 2.0 (Just say yes!)
I was working on an extremely long e-mail about this but Torsten, Stefano and a repentant Miles covered most of my points. Thanks for the help and for allowing me to waste my time :-P However... It seems that you are trying to do more then just replace the current functionality JXTG. You want to include the possibility processing the kitchen sink. I think this is what's bothering many of us. This will lead to breaking the separation of concerns. While implementing this in a template may seem better then implementing it in an XSP, in the end I suspect it will be just as ugly. The only thing that will change is the syntax. Semantically, it will be just as ugly. There is already too much power in the existing JXTG. On the other hand, I find the idea of a general template generator intriguing. I think you might be on to something, but I think you are missing it. Ok so you want a replacement for JXTG, create a tag library and have the template generator use it. You want the functionality of ESQL without XSP, create a tag library for it. Want to process CSVs, write a tag library for it. Want to process excel spreadsheets, create a tag library. The problem is that generally you declare the libraries in the document in which they are used and can use as many libraries as you want. This is where the evil part of tag libs comes in. It allows you to do anything and everything in one place. No separation of concerns can be enforced. View, controller, model all can be intermingled. Suppose, that instead of allowing all Tag Libraries to be used by the generator, each generator could only use one library. That is JXTG could only process JXTG tags, SQLTG could only process ESQL tags, ExcelTG could only process EXCEL tags, etc. TemplateGenerator is a perfect candidate for an abstract class. Each subclass just needs to have a Tag Library with which to work. This makes it much easier to implement other template generators just implement a new Tag Library and some constructors. Of course nothing prevents someone from adding multiple libraries to their generator should they choose to do so. They can deal with the consequences. This gives you the flexibility in design you want. It gives you the functionality that you want, since it is unlikely that you will want to access java objects and then access a database. It also helps limit the abuse that tag libraries can engender. Just my 0.02 . Now if I could just come up with a way to keep all html tags out of the JX templates. Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: review of sitemap component documentation
Luca Morandini wrote: At a glance I can see that Ant generator from scratchpad is missing (org.apache.cocoon.ant.AntBuildGenerator). Thanks Luca, that revealed a flaw in my 'find' script. I was expecting stuff to be organised in directories like org/apache/cocoon/.../generation/ etc. However, there are others like: org/apache/cocoon/ant/AntBuildGenerator.java So now i am finding based on filenames, e.g. *Generator.java Updated table coming soon. --David
Re: [ANN] Avalon Closed
On Friday 03 December 2004 14:28, Stephan Coboos wrote: And now, what happens with Cocoon? Are the developers of Cocoon now responsible theirselves to the unerlying Avalon framework? What are the plans for future? To remove all Avalon related classes from Cocoon? What are the replacements? If you read Aaron's post carefully, the Cocoon material is transferred to the Excalibur project. Furthermore, I think Carsten have already spawn ECM into ECM+ in Cocoon itself. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+
