running xupdate on xindice via cocoon
Hi all, I have some problem running xupdate on xindice via cocoon. These are what happened: WhenI run populate Xupdate sample coming with cocoon, with cocoon runing throw jetty i have the expected result. But when i run cocoon under tomcat all create instructions succeed but update and delete instructions failed. Should anyone please know what really wrong? For my applycation, i need cocoon running under tomcat and i also want to update my xindice database via cocoon. Any help is welcome. Thank a lot. regards Majirus Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !Créez votre Yahoo! Mail
Re: [Poll] Portal deployment / Cocoon portal usage
Responses inside. 1. Are you currently using the Cocoon Portal Framework? A) Yes we are using it for our Website under development 3. Why did you choose the Cocoon portal framework? A) We were already using Cocoon B) A strategic decision was made to use Open Source 4. What do you think is currently missing from the Portal framework? D) Better Documentation : Like any cocoon block new users would need more, but the code is there open :-). 5. How do you get support for the framework A) Through the mailing lists B) Reading the documentation and other publications 6. Details/Comments (Optional) As i said i can't compare to other portals, i believe it is today the biggest and most difficult block in cocoon, so i still lack experience. Still, i think it misses some flexibility concerning Layout and renderers. For example : - Change the disposition of tab,link-tab layout, put some coplets over the menus (Actually this is my question today on users-list: i don't think we can do much change there) - Access to the request and session inside the renderers - Possibilities to pass sitemap-parameters to the layout stylesheets Regards, Phil
Cocoon-2.1.X Tests Failure 01/25/05
Automated Cocoon Unit tests failed! Full log file if this unit test run is available here: http://nagoya.apache.org/~vadim/cocoon-test-log-20050125.log Last messages from the log file: == [foreach] reader-mime-type.xml:39: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:41: Running test [Header: Content-type = text/html ... done (1ms) [foreach] reader-mime-type.xml:39: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (112ms) [foreach] reader-mime-type.xml:44: Starting http://localhost:1///samples/test/reader-mime-type/test20.html [foreach] reader-mime-type.xml:46: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:44: Finished http://localhost:1///samples/test/reader-mime-type/test20.html (38ms) [foreach] reader-mime-type.xml:50: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:52: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:50: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (451ms) [foreach] reader-mime-type.xml:55: Starting http://localhost:1///samples/test/reader-mime-type/test30.html [foreach] reader-mime-type.xml:57: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:55: Finished http://localhost:1///samples/test/reader-mime-type/test30.html (87ms) [foreach] reader-mime-type.xml:61: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:63: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:61: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (21ms) [foreach] reader-mime-type.xml:66: Starting http://localhost:1///samples/test/reader-mime-type/test40.html [foreach] reader-mime-type.xml:68: Running test [Header: Content-type = text/html ... done (0ms) [foreach] reader-mime-type.xml:66: Finished http://localhost:1///samples/test/reader-mime-type/test40.html (27ms) [foreach] reader-mime-type.xml:72: Starting http://localhost:1///samples/test/reader-mime-type/test50.html [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = text/html[1;31m Failure: file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:74: message doesn't match because header 'content-type' is not present[m [foreach] ... done (7ms) [foreach] reader-mime-type.xml:72: Finished http://localhost:1///samples/test/reader-mime-type/test50.html (45ms) BUILD FAILED file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: Task at file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.7-dev/test/anteater/reader-mime-type.xml:72: failed Total time: 26 seconds Last messages from the server console: == [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 3 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 1383 ms. [EMAIL PROTECTED]: Startup sequence completed in 1424 ms. [EMAIL PROTECTED]: 2005-01-25 01:29:11.905 HSQLDB server 1.7.3 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 parameter = @PARAMETER@ replaceme = replaceme-abc parameter = @PARAMETER@ replaceme = replaceme-123 - 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_$_Tue_Jan_25_01:29:01_PST_2005 paused. - Scheduler Cocoon_$_Tue_Jan_25_01:29:01_PST_2005 shutting down. - Scheduler Cocoon_$_Tue_Jan_25_01:29:01_PST_2005 paused
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
WAIMS (where am i missing something ? :-)
XSP was designed to achieve exactly what you are describing. Sure it
has some limitations and the use of xslt to generate java code is not
exactly appealing, but it supports exactly that programmatic model.
Still everybody seems to hate it (I still use it, but only as a faster
way to write custom generators, not as a template language).
I think the reason is that what you want to achieve seems practical,
but it normally turns out in hell.
Example: the difference between get-users/ and ${get-users} is that
the first invoques a function (thus could trigger an exception) the
second refers to a variable, which, at worst, might be unset or empty
or contain a wrong value.
As soon as you realize this, you also realize that you need
conditionals in your language semantics... and if you hit the if
tag, you are dead.
What you are asking for are not taglibs but functional macros... the
ability to invoque a function/service/method instead of just reference
a variable... this allows you to drive the control directly from the
template, instead of having the control inverted by the flow controller.
I think this is a reasonable request and I see nothing wrong in it,
but these have nothing to do with taglibs, are more similar to what
input modules are for a sitemap.
Stefano,
The last two paragraphs are a little bit vague to me. I need your and
others opinions about how we should handle this in the refactored JXTG.
We are in the progress of factoring out the, (hopefully neutrally enough
named), instructions from the template execution engine and compiler.
This is for increasing maintainability, SOC and give the possiblity to
implement an attribute template language that reuse some of the parts.
We are also factoring out: expression language, parsing of strings with
embeded expressions and the object model.
Instruction Inclusion
=
Now for the instructions (jx:forEach etc) we have the question if they
should be choosed:
1. Programatically: There is an abstract base class with common template
generator functionality. To implement e.g. JXTG this base class is
extended. And the extended class enumerates the instructions that should
be used and also choose parsing strategy etc.
2. Configuration: Instructions or set of instructions are made
components and connected to the template generator in the configuration.
3. Within the template language: There are special instructions in some
common base template language that allow the user to include sets of
(Java written) instructions.
I would prefer the configuration way find the programatic way ok and be
against the within the template language way.
WDYT?
Instruction Access
==
What objects should instructions and macros be able to access? Curently
for the needs of the JXTG instructions, the instructions has access to a
ExpressionContext that contains the FOM view that is available in
expressions in JXTG. They also have access to an ExecutionContext that
currently contains a script manager and a map with macros, we might need
a SourceResolver also. There are also some other stuff that not are
relevant for the current discussion.
The questions are:
* Should the ExecutionContext also contain a ServiceManager?
* Should the ExpressionContext also contain a ServiceManager? (makes the
ServiceManager available in expressions)
IMO the ExecutionContext should have access to the ServiceManager and
the ExpressionContext shouldn't.
WDYT?
Both the above question might be suitable for votes, but I think they
need more discussion about them before we do that.
/Daniel
DO NOT REPLY [Bug 33231] New: - Wrong caching key for event pipeline
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=33231. 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=33231 Summary: Wrong caching key for event pipeline Product: Cocoon 2 Version: 2.1.6 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: core AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] Use Case: A cocoon-form (main-form) for changing user preferences has a ChangePassword button which will start a new cocoon-form (sub-form) within the same continuation. In case this sub-form uses a FileGenerator and a FormsTemplateTransformer a previously cached sub-form is shown instead of the newly created one! Simplified SiteMap scenario: The main sitemap uses an aggregation for assemblying all the parts of a page. The content of the page (sub-form) is delegated to a content.xmap. This sitemap uses a FileGenerator and the FormsTemplateTransformer which are both enclosed within a resource-exist. If we change this FileGenerator by a none-caching JxTemplateGenerator (which doesn't make any sense because no Jx processing is needed) the problem doesn't seem to occur. Debugging and logging shows us that the sitemap request for the sub-form (in case the FileGenerator is used) wrongly uses a previoulsy cached pipe. We think the AbstractCachingProcessingPipeline causes the problem. If we would know some backgrounds about how a caching key is determined for an event pipe it could help us in isolating the problem. We would appreciate it if anyone could give us any hints or tips for tracking down this issue or much better if someone could solve it :-) -- 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.
BugList of the old JX
Hi Since I started working with JX I have come accross some amazing bugs (probably like everyone) and thought a list of these might be usefull so that they are not forgotten and kept in the new one. To not do the same job twice, does such a list exist ? or are they declared in bugzilla ? Regards Tibor
Re: BugList of the old JX
oceatoon wrote: Hi Since I started working with JX I have come accross some amazing bugs (probably like everyone) and thought a list of these might be usefull so that they are not forgotten and kept in the new one. To not do the same job twice, does such a list exist ? or are they declared in bugzilla ? bugzilla is just fine for those cases. If there are plenty we can always create a common parent and put link to wiki. -- 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: sitemap, jx and flow design (was: servicemanager and jxtg)
Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
WAIMS (where am i missing something ? :-)
XSP was designed to achieve exactly what you are describing. Sure it has
some limitations and the use of xslt to generate java code is not
exactly appealing, but it supports exactly that programmatic model.
Still everybody seems to hate it (I still use it, but only as a faster
way to write custom generators, not as a template language).
I think the reason is that what you want to achieve seems practical, but
it normally turns out in hell.
Example: the difference between get-users/ and ${get-users} is that
the first invoques a function (thus could trigger an exception) the
second refers to a variable, which, at worst, might be unset or empty or
contain a wrong value.
Understood. The difference is subtile. get-users/ is a data from the user
point of view (he can put it inside a variable), but its true that the
component responsible for returning the value might trigger an exception
and i'm agree this is bad because we are already in the view space. Well
thought.
But jx (with his ability for calling method on java objects), is not anymore
a pure view template language. $session, $request, ... are already objects
not dom nor pure bean objects.
As soon as you realize this, you also realize that you need conditionals
in your language semantics... and if you hit the if tag, you are dead.
Yep.
What you are asking for are not taglibs but functional macros... the
ability to invoque a function/service/method instead of just reference a
variable... this allows you to drive the control directly from the
template, instead of having the control inverted by the flow controller.
I never a thought about the MVC design because actual jx implementation is
already outside of this pattern. I'm totaly happy with the functionnal
macros name ;-)
I think this is a reasonable request and I see nothing wrong in it, but
these have nothing to do with taglibs, are more similar to what input
modules are for a sitemap.
Ok. So what about turning on the ability to pass dom inside sitemap
parameters ?
1) pipeline more clear
generate type=jx src=..
parameter name=auth dom={session-context:authentication}/
/generate
2) servicemanager, $request, $session useless in jx (pass parameters
explicitly in the sitemap like you use to do with SendPage in flow). SoC
preserved.
3) inversion of control not broken. (Exception triggered from the sitemap).
You can remove java object access from jx since they are used for breaking
this IoC and SoC.
We use to do (well, a bad habit :-)
jx:setjx:import src=cocoon:/userprofile//jx:set
inside templates. This break SoC and IoC too.
Oceatoon (tibor ;-) make me think of another advantage of passing dom with
parameters.
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
which is much more readeable and doesn't break anything.
WDYT ?
DO NOT REPLY [Bug 33233] New: - [PATCH] Portal: TabContentAcspect: Added parameters show-all-nav and include-selected
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=33233. 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=33233 Summary: [PATCH] Portal: TabContentAcspect: Added parameters show-all-nav and include-selected Product: Cocoon 2 Version: Current SVN 2.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: blocks AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] This Patch allows to generate enclosed named-items without setting the 'child- tag-name' parameter. The parameter 'show-all-nav' forces that the enclosed named-items are rendered (without content) and the parameter 'include- selected' allows to output the enclosed named-items of the selected named-item too. If only the 'child-tag-name' parameter is set the behavior of the class should be as it was before. -- 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.
DO NOT REPLY [Bug 33233] - [PATCH] Portal: TabContentAcspect: Added parameters show-all-nav and include-selected
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=33233. 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=33233 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 12:50 --- Created an attachment (id=14091) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14091action=view) Patch for TabContentAspect -- 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.
DO NOT REPLY [Bug 33234] New: - JXTemplate Bug List(For Refactoring info)
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=33234.
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=33234
Summary: JXTemplate Bug List(For Refactoring info)
Product: Cocoon 2
Version: Current SVN 2.2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
The jx:set var=myvarany string/jx:set
${myvar} will be empty when used.
hack is to pass by jx:macros
--
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.
DO NOT REPLY [Bug 33234] - JXTemplate Bug List(For Refactoring info)
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=33234. 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=33234 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 13:00 --- are you invoking the template from flow or directly from pipeline? -- 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: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote: Instruction Access == What objects should instructions and macros be able to access? Curently for the needs of the JXTG instructions, the instructions has access to a ExpressionContext that contains the FOM view that is available in expressions in JXTG. They also have access to an ExecutionContext that currently contains a script manager and a map with macros, we might need a SourceResolver also. There are also some other stuff that not are relevant for the current discussion. The questions are: * Should the ExecutionContext also contain a ServiceManager? * Should the ExpressionContext also contain a ServiceManager? (makes the ServiceManager available in expressions) IMO the ExecutionContext should have access to the ServiceManager and the ExpressionContext shouldn't. WDYT? Both the above question might be suitable for votes, but I think they need more discussion about them before we do that. -1 if we can pass dom (perhaps bean too) with pipeline parameter (see my answer to stefano). +1 otherwise. What about starting defining a functionnal macros API, so that cforms could plug properly in jx ? /Daniel
DO NOT REPLY [Bug 33234] - JXTemplate Bug List(For Refactoring info)
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=33234. 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=33234 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 13:09 --- from flow -- 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.
DO NOT REPLY [Bug 33236] New: - Jx:set type ??? (JXTemplate Bug List)
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=33236.
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=33236
Summary: Jx:set type ??? (JXTemplate Bug List)
Product: Cocoon 2
Version: Current SVN 2.2
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
jx:set var=logid
value=${session.getAttribute('my_key/authentication')}/
jx:set var=userid value=#{$logid/ID}/
jx:if test=#{$logid/ID}
returns true or false according to the existence of the ID, so far so good
OTH
jx:if test=#{$userid/ID} returns always true , bug???
--
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: Planning 2.1.7
Gregor J. Rothfuss wrote: Carsten Ziegeler wrote: Hello, what do you think of a 2.1.7 release in the near future - middle of February for example? sounds good. maybe it would make sense for cocoon to have a relase plan similar to http://wiki.apache.org/lenya/ReleasePlan ? it would help lenya (and other cocoon-dependent) projects if there was a timeframe for new cocoon releases. we always try to release lenya versions with the latest cocoon version, but sometimes the timing does not work out. Oh, we have a roadmap: http://cocoon.apache.org/2.1/plan/roadmap.html :) I'm not sure if setting a date upfront would help us getting a better release. We take the time we need to provide the quality for a release. Carsten
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
BURGHARD Éric wrote:
snip/
Ok. So what about turning on the ability to pass dom inside sitemap
parameters ?
1) pipeline more clear
generate type=jx src=..
parameter name=auth dom={session-context:authentication}/
/generate
I don't get why you are so obsessed with being able to do everything
from the sitemap. Once, when the community started to develop Cocoon in
a direction to better support webapps there was the question if we
should put more abilities to have control stuff in the pipeline or if
this should be done in a separate system, the flowscript. Had we chosen
the sitemap way we would have need to put more mechanisms in the sitemap
to preserve nice SOC. That was the way I prefered back then.
Now we have gone the flowscript way and I'm completely happy with that.
There are nummerous good reasons for that decision and some good reason
against it. But in some way that doesn't matter anymore. What is much
more important is that we focus our energy on making Cocoon realy smooth
and efficient to use along the choosen direction. Trying to support
several similar ways of achieving the same things only disolve our energy.
Whats important to notice for software development is that if enough
talented people choose an at least somewhat reasonable direction and
focus on, it _makes_ the direction a good direction after a while. To be
worthwhile to backtrack and chose another direction must lead to very
large advantages to be anything else but destructive.
Conclusion: the current direction is that objects and control are
handled in flowscript rather than pipelines. Let us focus on making that
smooth rather than confusing our users and ourselves about where things
should be done.
2) servicemanager, $request, $session useless in jx (pass parameters
explicitly in the sitemap like you use to do with SendPage in flow). SoC
preserved.
3) inversion of control not broken. (Exception triggered from the sitemap).
You can remove java object access from jx since they are used for breaking
this IoC and SoC.
Ok, you have removed the programming from JXTG and put it in the
sitemap instead, whats the gain?
We use to do (well, a bad habit :-)
jx:setjx:import src=cocoon:/userprofile//jx:set
inside templates. This break SoC and IoC too.
Oceatoon (tibor ;-) make me think of another advantage of passing dom with
parameters.
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
You could do it from a flowscript, whats the problem with that?
which is much more readeable and doesn't break anything.
WDYT ?
No thanks ;)
/Daniel
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
BURGHARD Éric wrote: Daniel Fagerstrom wrote: Instruction Access == What objects should instructions and macros be able to access? Curently for the needs of the JXTG instructions, the instructions has access to a ExpressionContext that contains the FOM view that is available in expressions in JXTG. They also have access to an ExecutionContext that currently contains a script manager and a map with macros, we might need a SourceResolver also. There are also some other stuff that not are relevant for the current discussion. The questions are: * Should the ExecutionContext also contain a ServiceManager? * Should the ExpressionContext also contain a ServiceManager? (makes the ServiceManager available in expressions) IMO the ExecutionContext should have access to the ServiceManager and the ExpressionContext shouldn't. WDYT? Both the above question might be suitable for votes, but I think they need more discussion about them before we do that. -1 if we can pass dom (perhaps bean too) with pipeline parameter (see my answer to stefano). +1 otherwise. What about starting defining a functionnal macros API, so that cforms could plug properly in jx ? I'm more interested in making cforms more template friendly. /Daniel
Re: xml languages
Leszek Gawron wrote: Daniel Fagerstrom wrote: Another possibility is to let set asign the value to the first variable binding with the same name that it finds when the stack is searched, -1. Don't think this is a possibility; as noted above, templates should be side effect free. Glad that you agree :) Eric and Leszek are not convinced at all and want real assignment. Not 100% true. When introducing the assignment I have always thought about JXTG internal variables. I did not realize it could be also used to modify the model passed to the view. So how about the solution that the execution context has 2 levels on the start: snip/ I think I was not clear enough; I'm against allowing jx:set to change value of any internal to JXTG variable too. This will force you to do more complicated stuff (which is usually done using procedural approach) somewhere outside of JXTG, and in JXTG you use jx:set similarly to XSLT's xsl:variable, to hold immutable computed value within current execution scope. Vadim
Re: Difference between FOM_Session and REal Session?
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: oceatoon wrote: Why step away from the global session though, and create a new FOM_session structure? your answer was design decision but I don't understand, why ? Neither do I, it wasn't my decison but Chris Olivers. One reason might be that flow uses a special embedinging of the request object etc to make them easy to use in Java script, FOM's FOM_Cocoon / FOM_Request / etc objects are results of conscious community effort to define FOM (Flow Object Model), all its objects, and all methods on those objects. You will notice that not all methods of underlying Cocoon Request / Response / etc API were exposed, and this was done for a reason. Thanks for reminding. IIRC, see archives for thread less is more. I searched the archives and found lots of discussions about it but not any summary of the actual decision. The goal is to have the FOM view from JXTG available in other places in Cocoon, e.g. in an ExpressionModule. To achive this I used Carsten's TemplateObjectModelHelper, that makes the same object available as the FOM in flowscript. But it does that through a reflection based dynamic map instead of by implementing the interface in a JS friendly way as in the flowscript implementation.This makes, if I understand you right more methods available than it should. Is that important? What do yo think we should do about it? /Daniel
DO NOT REPLY [Bug 33237] New: - [PATCH] CForm definitions using JXTemplate
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=33237.
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=33237
Summary: [PATCH] CForm definitions using JXTemplate
Product: Cocoon 2
Version: Current SVN 2.1
Platform: PC
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
This is a patch that I needed to implement for a project I'm working on and that
someone else may find useful. I have CForm definitions being created with a
JXTemplate instead of a static XML file and needed to be able to pass some
objects through to the JXTemplate. This patch allows me to create forms like:
var form = new Form(cocoon:/form1.jx, {bean : bean});
form.createBinding(cocoon:/form1Bind.jx, null, {bean : bean});
and then from within the JXTemplate I can use the objects like ${bean.foo}
There's probably a better way to do the changes I made in Form.js, but this is
what I'm using in my project at the moment so hopefully someone will find it
useful.
--
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.
DO NOT REPLY [Bug 33237] - [PATCH] CForm definitions using JXTemplate
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=33237. 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=33237 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 14:50 --- Created an attachment (id=14092) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14092action=view) JXTemplateGenerator.java.diff -- 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.
DO NOT REPLY [Bug 33237] - [PATCH] CForm definitions using JXTemplate
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=33237. 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=33237 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 14:50 --- Created an attachment (id=14093) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14093action=view) Form.js.diff -- 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.
DO NOT REPLY [Bug 33237] - [PATCH] CForm definitions using JXTemplate
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=33237. 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=33237 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 14:51 --- Created an attachment (id=14094) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14094action=view) FormUtil.java -- 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: sitemap, jx and flow design (was: servicemanager and jxtg)
Hi this thread is getting quite complicated to follow and the snake seems to be bighting it's own tail;) , but the idea is quite simple and seems an easy patch. I don't get why you are so obsessed with being able to do everything from the sitemap. Once, when the community started to develop Cocoon in a direction to better support webapps there was the question if we should put more abilities to have control stuff in the pipeline or if this should be done in a separate system, the flowscript. Had we chosen the sitemap way we would have need to put more mechanisms in the sitemap to preserve nice SOC. That was the way I prefered back then. Eric's proposal of passing objects (like DOM) as sitemap parameters in pipeline, IMO would be compared to jx:import(with a pipeline as uri) and loadDocument(cocoon://blabla) in flow, So why not be able to pass directly any kind of DOM in sitemap as a parameter? (for example coming from a session context or other IM) Now we have gone the flowscript way and I'm completely happy with that. There are nummerous good reasons for that decision and some good reason against it. But in some way that doesn't matter anymore. What is much more important is that we focus our energy on making Cocoon realy smooth and efficient to use along the choosen direction. Trying to support several similar ways of achieving the same things only disolve our energy. Whats important to notice for software development is that if enough talented people choose an at least somewhat reasonable direction and focus on, it _makes_ the direction a good direction after a while. To be worthwhile to backtrack and chose another direction must lead to very large advantages to be anything else but destructive. I think we all agree on the above, but also know that we all have different ways of solutionning the same problem. The quantity of solutions proposed by the cocoon structure is part of its charm ;) Conclusion: the current direction is that objects and control are handled in flowscript rather than pipelines. Let us focus on making that smooth rather than confusing our users and ourselves about where things should be done. IMO, it isn't more complicated than the other two cases, just the possibility to pass an object as a parameter. 2) servicemanager, $request, $session useless in jx (pass parameters explicitly in the sitemap like you use to do with SendPage in flow). SoC preserved. 3) inversion of control not broken. (Exception triggered from the sitemap). You can remove java object access from jx since they are used for breaking this IoC and SoC. I understand that the SiteMap plays the central role in the simplified pyramidal design of Cocoon(Sitemap,Flow,JX) but is restrained in the type of parameters it passes(strings) to either JX or Flow. OTOH Flow is able to pass any type of objects in a SendPage which is enormously usefull. And poor old JX spits out whatever the other two Controllers giv'him. I find it normal that the sitemap could give him DOM, or any other object. SoC and IoC truly are truly respected here. Tibor
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
snip/
I'm not obsessed trust me (by the sitemap at least :-).
But certainly i was not clear. I dislike actions (which is the kind of
control you don't want in the sitemap too), and prefer flow for controling
workflow as you do. My previous example has nothing to do with workflow.
It's a pure template that is feeded (respectfull to IoC and SoC) by the
sitemap controller (as you probably know flow is not the only one
controller) in one line and with a syntax which everybody could understand.
pipeline match=allinone
generate type=jx src=..
!-- pass authentication dom to jx --
parameter name=auth dom={session-context:authentication}/
/generate
...
/map:
The same example could be done in sitemap+flow, but look how !
sitemap.xmap
---
flow language=javascript
script src=myfunc.js/
/map:flow
pipeline match=begin
call function=myfunc
/pipeline
pipeline match=returntositemap
generate type=jx src=.../
...
/pipeline
myfunc.js
--
function myfunc () {
uri = cocoon:/getuser;
parser =
cocoon.getComponent(Packages.org.apache.excalibur.xml.dom.DOMParser.ROLE);
resolver =
cocoon.getComponent(Packages.org.apache.cocoon.environment.SourceResolver.ROLE);
source = resolver.resolveURI(uri);
var is = new
Packages.org.xml.sax.InputSource(source.getInputStream());
is.setSystemId(source.getURI());
dom = parser.parseDocument(is);
$cocoon.SendPage(returntositemap, dom)
}
Whow ! that's a lot of things for beginners. But that's not really
important. The worst is that i need to go though flow (again no workflow
here), and that it blur my vision of what's happening between begin and
returntositemap. All that for a poor little template.
I have never disputed that things might be clumsy now, I just think we
should focus on getting the flowscript way better, instead of adding
things that makes the sitemap more of a programming language, by
handling a more diverse set of datatypes then strings. With what I
propse your example would be:
sitemap.xmap
---
flow language=javascript
script src=myfunc.js/
/map:flow
pipeline match=begin
call function=myfunc
generate type=jx src=.../
...
/pipeline
myfunc.js
--
function myfunc () {
pipeutil =
cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil);
return { dom: pipeutil.processToDOM(/getuser) }
}
Where the pipeline util allready exists since a year or so.
Thats what I'm going to focus on. I'm certain that there are good
reasons for other solutions, but IMO we should focus on having one
_excelent_ way of doing things rather than a couple of ok and
independently developed, ways following different paradigms and focusing
on different use cases and diffusing the development effort. But thats
just me, do what you want.
/Daniel
DO NOT REPLY [Bug 33237] - [PATCH] CForm definitions using JXTemplate
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=33237. 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=33237 --- Additional Comments From [EMAIL PROTECTED] 2005-01-25 18:05 --- Mmmh... Looks a bit weird to me... Aren't request parameters enough, e.g. new Form(cocoon:/form1.jx?x=fooy=baz) Another way to do the same is to use PipelineUtils.processToDOM() and then use the DOM to build the form. WDYAT? -- 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: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
WAIMS (where am i missing something ? :-)
XSP was designed to achieve exactly what you are describing. Sure it
has some limitations and the use of xslt to generate java code is not
exactly appealing, but it supports exactly that programmatic model.
Still everybody seems to hate it (I still use it, but only as a faster
way to write custom generators, not as a template language).
I think the reason is that what you want to achieve seems practical,
but it normally turns out in hell.
Example: the difference between get-users/ and ${get-users} is that
the first invoques a function (thus could trigger an exception) the
second refers to a variable, which, at worst, might be unset or empty
or contain a wrong value.
As soon as you realize this, you also realize that you need
conditionals in your language semantics... and if you hit the if
tag, you are dead.
What you are asking for are not taglibs but functional macros... the
ability to invoque a function/service/method instead of just reference
a variable... this allows you to drive the control directly from the
template, instead of having the control inverted by the flow controller.
I think this is a reasonable request and I see nothing wrong in it,
but these have nothing to do with taglibs, are more similar to what
input modules are for a sitemap.
Stefano,
The last two paragraphs are a little bit vague to me. I need your and
others opinions about how we should handle this in the refactored JXTG.
We are in the progress of factoring out the, (hopefully neutrally enough
named), instructions from the template execution engine and compiler.
This is for increasing maintainability, SOC and give the possiblity to
implement an attribute template language that reuse some of the parts.
We are also factoring out: expression language, parsing of strings with
embeded expressions and the object model.
Daniel, thanks for the summary. Read my comments below.
Instruction Inclusion
=
Now for the instructions (jx:forEach etc) we have the question if they
should be choosed:
1. Programatically: There is an abstract base class with common template
generator functionality. To implement e.g. JXTG this base class is
extended. And the extended class enumerates the instructions that should
be used and also choose parsing strategy etc.
2. Configuration: Instructions or set of instructions are made
components and connected to the template generator in the configuration.
3. Within the template language: There are special instructions in some
common base template language that allow the user to include sets of
(Java written) instructions.
I would prefer the configuration way find the programatic way ok and be
against the within the template language way.
WDYT?
This really looks like just an implementation detail... I would think
that the configuration way makes it easier (psycologically) for people
to add their own instructions than the other two. #1 is cleaner than #3
and less avalonish than #2.
I'm not thrilled with the idea of people adding their own keywords to
the template language... just like the sitemap, it should be possible
but not easy, so that people would feel discouradged to do it. So
probably #1 would be my choice.
Instruction Access
==
What objects should instructions and macros be able to access? Curently
for the needs of the JXTG instructions, the instructions has access to a
ExpressionContext that contains the FOM view that is available in
expressions in JXTG. They also have access to an ExecutionContext that
currently contains a script manager and a map with macros, we might need
a SourceResolver also. There are also some other stuff that not are
relevant for the current discussion.
The questions are:
* Should the ExecutionContext also contain a ServiceManager?
* Should the ExpressionContext also contain a ServiceManager? (makes the
ServiceManager available in expressions)
IMO the ExecutionContext should have access to the ServiceManager and
the ExpressionContext shouldn't.
WDYT?
Agreed. Seems reasonable.
--
Stefano.
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
BURGHARD Éric wrote:
Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
WAIMS (where am i missing something ? :-)
XSP was designed to achieve exactly what you are describing. Sure it has
some limitations and the use of xslt to generate java code is not
exactly appealing, but it supports exactly that programmatic model.
Still everybody seems to hate it (I still use it, but only as a faster
way to write custom generators, not as a template language).
I think the reason is that what you want to achieve seems practical, but
it normally turns out in hell.
Example: the difference between get-users/ and ${get-users} is that
the first invoques a function (thus could trigger an exception) the
second refers to a variable, which, at worst, might be unset or empty or
contain a wrong value.
Understood. The difference is subtile. get-users/ is a data from the user
point of view (he can put it inside a variable), but its true that the
component responsible for returning the value might trigger an exception
and i'm agree this is bad because we are already in the view space. Well
thought.
But jx (with his ability for calling method on java objects), is not anymore
a pure view template language. $session, $request, ... are already objects
not dom nor pure bean objects.
As soon as you realize this, you also realize that you need conditionals
in your language semantics... and if you hit the if tag, you are dead.
Yep.
What you are asking for are not taglibs but functional macros... the
ability to invoque a function/service/method instead of just reference a
variable... this allows you to drive the control directly from the
template, instead of having the control inverted by the flow controller.
I never a thought about the MVC design because actual jx implementation is
already outside of this pattern. I'm totaly happy with the functionnal
macros name ;-)
I think this is a reasonable request and I see nothing wrong in it, but
these have nothing to do with taglibs, are more similar to what input
modules are for a sitemap.
Ok. So what about turning on the ability to pass dom inside sitemap
parameters ?
Hmmm, I don't have a problem in passing more structured data-structures
as sitemap parameters.
1) pipeline more clear
generate type=jx src=..
parameter name=auth dom={session-context:authentication}/
/generate
but I don't like dom=, I don't think we have to type them.
2) servicemanager, $request, $session useless in jx (pass parameters
explicitly in the sitemap like you use to do with SendPage in flow). SoC
preserved.
3) inversion of control not broken. (Exception triggered from the sitemap).
You can remove java object access from jx since they are used for breaking
this IoC and SoC.
We use to do (well, a bad habit :-)
jx:setjx:import src=cocoon:/userprofile//jx:set
inside templates. This break SoC and IoC too.
Oceatoon (tibor ;-) make me think of another advantage of passing dom with
parameters.
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
uh, that's pretty cool I have to say.
which is much more readeable and doesn't break anything.
WDYT ?
+1 as long as you don't call it dom= but you leave it as value= and
you let the consumers deal with their type checking (don't know if this
is at all possible, but you get my idea).
--
Stefano.
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote:
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
You could do it from a flowscript, whats the problem with that?
Wait. You can do a lot of things with flow, but I also think that we
should not forget about what we already have.
The sitemap already contains input modules and as much as I was not
thrilled by them, I came to agree that sometimes they are very useful,
because while flow is great for stateful content, using it for stateless
dispatching looks really like a waste and I think we are pushing flow so
much that people will start to abuse it as a procedural dispatch mechanism.
What you are asking and what Éric is asking are two different things: he
is asking to allow better integration between sitemap and data
generation and you are telling him that thou shall use flow.
There are situations where using flow doesn't make sense at all and
sitemaps still feel like the best tool for the job.
What Éric proposes is a reasonable and back-compatible extention to the
sitemap semantics that would allow much easier reuse of pipeline
machinery for internal data generation and consumption.
This has nothing to do the template language design.
--
Stefano.
I am looking for a Cacoon Consultant . can you help
Organisation that is a leader in it's field requires a Snr Java Developer with in depth knowledge of Cocoon for an initial three month assignment to be based in West London. The customer is looking for the successful candidate to come in and build a parallel proto-type of the current corporate Website using Java/Cacoon, the role will also involve mentoring and coaching permanent members of staff in Cacoon. Please contact me or pass my details on to anyone this may be of interest to . Regards Marcus Clemens Senior Consultant Vector Resourcing Ltd Tel: 01892 771447 Fax: 01892 777992 Castle Farm Barn, Hartfield, East Sussex, TN7 4JD This email may contain privileged/confidential information and is for the intended addressee only. If you have received this message in error then you must not use, retain, disseminate or otherwise deal with it. Please notify the sender by return email and destroy. The views of the author may not necessarily constitute the views of Vector Resourcing Ltd. Nothing in this email shall bind Vector Resourcing Ltd in any contract or obligation. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: snip/ Stefano, The last two paragraphs are a little bit vague to me. I need your and others opinions about how we should handle this in the refactored JXTG. We are in the progress of factoring out the, (hopefully neutrally enough named), instructions from the template execution engine and compiler. This is for increasing maintainability, SOC and give the possiblity to implement an attribute template language that reuse some of the parts. We are also factoring out: expression language, parsing of strings with embeded expressions and the object model. Daniel, thanks for the summary. Read my comments below. Instruction Inclusion = Now for the instructions (jx:forEach etc) we have the question if they should be choosed: 1. Programatically: There is an abstract base class with common template generator functionality. To implement e.g. JXTG this base class is extended. And the extended class enumerates the instructions that should be used and also choose parsing strategy etc. 2. Configuration: Instructions or set of instructions are made components and connected to the template generator in the configuration. 3. Within the template language: There are special instructions in some common base template language that allow the user to include sets of (Java written) instructions. I would prefer the configuration way find the programatic way ok and be against the within the template language way. WDYT? This really looks like just an implementation detail... I would think that the configuration way makes it easier (psycologically) for people to add their own instructions than the other two. #1 is cleaner than #3 and less avalonish than #2. I'm not thrilled with the idea of people adding their own keywords to the template language... just like the sitemap, it should be possible but not easy, so that people would feel discouradged to do it. So probably #1 would be my choice. Ok, if no one protests I think we go for #1. It give us more flexiblity in refining the instruction interface than if we publish it as an external interface. We can always do it configurable later if the need is feeled. Instruction Access == What objects should instructions and macros be able to access? Curently for the needs of the JXTG instructions, the instructions has access to a ExpressionContext that contains the FOM view that is available in expressions in JXTG. They also have access to an ExecutionContext that currently contains a script manager and a map with macros, we might need a SourceResolver also. There are also some other stuff that not are relevant for the current discussion. The questions are: * Should the ExecutionContext also contain a ServiceManager? * Should the ExpressionContext also contain a ServiceManager? (makes the ServiceManager available in expressions) IMO the ExecutionContext should have access to the ServiceManager and the ExpressionContext shouldn't. WDYT? Agreed. Seems reasonable. Ok, good. /Daniel
RE: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote: Instruction Inclusion = Now for the instructions (jx:forEach etc) we have the question if they should be choosed: 1. Programatically: There is an abstract base class with common template generator functionality. To implement e.g. JXTG this base class is extended. And the extended class enumerates the instructions that should be used and also choose parsing strategy etc. 2. Configuration: Instructions or set of instructions are made components and connected to the template generator in the configuration. 3. Within the template language: There are special instructions in some common base template language that allow the user to include sets of (Java written) instructions. What kind of instructions did you have in mind? The reason I ask is I wonder if it's really necessary to add extra instructions to the template language? A language with conditionals, iteration, AND recursion is surely already Turing-complete, and doesn't really need more control structures? Con
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Conal Tuohy wrote: Daniel Fagerstrom wrote: Instruction Inclusion = Now for the instructions (jx:forEach etc) we have the question if they should be choosed: 1. Programatically: There is an abstract base class with common template generator functionality. To implement e.g. JXTG this base class is extended. And the extended class enumerates the instructions that should be used and also choose parsing strategy etc. 2. Configuration: Instructions or set of instructions are made components and connected to the template generator in the configuration. 3. Within the template language: There are special instructions in some common base template language that allow the user to include sets of (Java written) instructions. What kind of instructions did you have in mind? Take a look at src/blocks/template/java/org/apache/cocoon/template/jxtg/instruction/* in trunk. It is al the jx:* stuff in JXTG. We are factoring out the instructions from the execution engine and the compiler to be able to reuse the different part in e.g. an attribute template language, see http://wiki.apache.org/cocoon/Templates for more details. The refactoring is also to make JXTG more maintainable. The reason I ask is I wonder if it's really necessary to add extra instructions to the template language? A language with conditionals, iteration, AND recursion is surely already Turing-complete, and doesn't really need more control structures? We probably shouldn't add new types of instructions. But some of the current instructions have design flaws as you can see in some other current threads. E.g. jx:set is somewhere between the declarative xsl:variable and an asignement in e.g. Java. jx:eval requires quite strange hacks to be usable, jx:import makes pre compilation of macros hard (or impossible), there might be other issues as well. If we just corrects the current construction that will break existing templates, and we don't want that. So the best things is probably to add new more well behaved instructions and possibly deprecate some of the old. An alternativ would be support both a JXTG 1.0 and JXTG 2.0 and remove the instructions we don't like from JXTG 2.0. But currently it seem smother to go for the evolutionary approach. /Daniel
Re: CONTRIBUTION: repeater-widget (insert row): InsertRowsActionDefinition
Hi David, On 25 Jan 2005, at 01:36, depub2 wrote: I would like to make a small contribution to the cocoon repeater-widget (insert row) and would like someone (Sylvain Wallez?) to accept my code; so I'll be a ghostwriter as it does not make sense for me to maintain this small piece of code. The best way to contribute this is to submit it as a patch via bugzilla, then as soon as someone (perhaps Sylvain!) gets a chance, they will be able to review it and add it to Cocoon. Information on creating diffs can be found here: http://cocoon.apache.org/community/ contrib.html#How+to+Generate+Differences Bugzilla can be found here: http://issues.apache.org/bugzilla/ Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Lazy mode and compiling classloader (was Re: FOM input modules)
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
After some experiments with the new compiling classloader stuff, I
personally don't feel a need for a scripting action solution. But
this highly depends on your skills.
Interesting, do you mean that you write ordinary actions and use the
compiling classloader on them?
I tried it and it worked for me. Currently, *you* have to make sure
that the sitemap reloads (e.g. adding a space character) but if I
understood Sylvain's mail to his lazy mode implementation correctly,
this will help to get rid of this (ugly) workaround.
Ahem, no: the lazy mode only loads (and therefore compiles) components
the first time they are looked up in the service manager. That means
that currently you have to touch the sitemap in order for classes to
be reloaded.
But the actual purpose of the lazy mode is not only fast startup time,
but also fast *reload* time: the idea is that when a source file is
changed, Cocoon is restarted in the same way as a ?cocoon-reload=true,
therefore recompiling everything that needs to be recompiled and
garbaging all instances of the previous versions of recompiled classes.
But that reloading isn't there yet.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM input modules
Carsten Ziegeler wrote:
Hmm, the question is: how can a pluggable object model work - or how
can it be extended? What about using...input modules for exactly this?
We create a way of mounting input modules into the object model,
like this:
object-model
mount input-module=skin path=cocoon.skin/
/object-model
And then you can simple access the info by ${cocoon.skin.something}.
I like it. Object model and input modules are just different names for
similar things: accessing environmental data. Also, it's better to
attach IMs to the cocoon object rather than as root variables, as it
avoids name clashes with template variables.
Something we have to be careful of, though, is that properties of the
cocoon object comes both from the OM (request, response, context) and
modules, and that it should be forbidden to have IMs having the same
name as OM keys.
I also would like to insist on the fact that FOM (flow object model) is
nothing more than OM (object model) that we have everywhere in Cocoon,
but rewrapped as JS objects. So we should better concentrate on the OM
itself and let its JS counterpart follow its evolutions.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
DO NOT REPLY [Bug 30928] - [Patch] XMLDBSource should accept scheme://user:pass@host:port/path URIs
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=30928.
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=30928
--- Additional Comments From [EMAIL PROTECTED] 2005-01-26 00:00 ---
(In reply to comment #0)
It should be possible to have the following in the sitemap:
map:generate
src=xmldb:db://{session-attr:user}:{session-attr:[EMAIL
PROTECTED]:port/db/etc.xml /
I got trouble to connect to xindice under THIS procedure on a winXP machine,
but I think, that this is a machine independent unavailable feature / problem.
Create this problem:
- install tomcat
- dropped xindice-1.1b4.war into tomcats webapps directory
- xindice is available as webapp (ugly debug tool)
- prepare for commandline tool
- access to local database through commandline not possible via:
xindice ... -c xmldb:xindice://localhost:%myPort%/db/ ...
reason:
---
directory mapping not sufficient
solution:
-
connection works when xindice is located at
%CATALINA_HOME%/webapps/xindice
Well ... you maybe can maybe fix this by adding a mapping to
xindice's webapp config, but that's not the way it SHOULD behave.
Xindice should use an port to comunicate with console-client so that
connection allways succeds, when a correct machine and port ist given.
Port obviously will be not the one on which tomcat can be accessed.
--
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: FOM input modules
On Tue, 25 Jan 2005 23:58:41 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote: snip/ I also would like to insist on the fact that FOM (flow object model) is nothing more than OM (object model) that we have everywhere in Cocoon, but rewrapped as JS objects. So we should better concentrate on the OM itself and let its JS counterpart follow its evolutions. +1 Yes, please. -- Peter Hunsberger
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
You could do it from a flowscript, whats the problem with that?
Wait. You can do a lot of things with flow, but I also think that we
should not forget about what we already have.
The sitemap already contains input modules and as much as I was not
thrilled by them, I came to agree that sometimes they are very useful,
because while flow is great for stateful content, using it for stateless
dispatching looks really like a waste and I think we are pushing flow so
much that people will start to abuse it as a procedural dispatch mechanism.
What you are asking and what Éric is asking are two different things: he
is asking to allow better integration between sitemap and data
generation and you are telling him that thou shall use flow.
Seem to me like we have switched opinion with each other ;)
You know, over the last few years I have written tons of RTs describing
more or less cool pipeline constructions for simplifying webapp
development. And you have after more or less convincing argumentation
stated: thou shall use flow and concluded with your obligatory -1.
My current interest is polishing the basic building blocks for building
webapps: JXTG, flow, CForms and maybe some more stuff so that it becomes
as coherent and smooth as possible and in some cases less monolithic.
Having such a gool I am more interested in seeing the usual I don't
want to use flow because of X for something that seem close to the
concern area for flow, as a good reason for discussing how to polish
flow so that it fullfills its task better.
Maybe handling data types other than strings; DOM, Java Beans, SQL
rowsets etc in the sitemap is an excelent idea. But my gut feeling,
after having spend considerable time thinking about building webapps
with sitemap constructions, is that it doesn't stop there, we need some
other sitemap constructions to make it really useful. And as said I feel
more for polishing the flowscript way, than being part of developing
alternative solutions. But you don't need my blessing for discussing and
developing such things if you feel a need for it.
/Daniel
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
You could do it from a flowscript, whats the problem with that?
Wait. You can do a lot of things with flow, but I also think that we
should not forget about what we already have.
The sitemap already contains input modules and as much as I was not
thrilled by them, I came to agree that sometimes they are very useful,
because while flow is great for stateful content, using it for
stateless dispatching looks really like a waste and I think we are
pushing flow so much that people will start to abuse it as a
procedural dispatch mechanism.
What you are asking and what Éric is asking are two different things:
he is asking to allow better integration between sitemap and data
generation and you are telling him that thou shall use flow.
Seem to me like we have switched opinion with each other ;)
You know, over the last few years I have written tons of RTs describing
more or less cool pipeline constructions for simplifying webapp
development. And you have after more or less convincing argumentation
stated: thou shall use flow and concluded with your obligatory -1.
My current interest is polishing the basic building blocks for building
webapps: JXTG, flow, CForms and maybe some more stuff so that it becomes
as coherent and smooth as possible and in some cases less monolithic.
Having such a gool I am more interested in seeing the usual I don't
want to use flow because of X for something that seem close to the
concern area for flow, as a good reason for discussing how to polish
flow so that it fullfills its task better.
Maybe handling data types other than strings; DOM, Java Beans, SQL
rowsets etc in the sitemap is an excelent idea. But my gut feeling,
after having spend considerable time thinking about building webapps
with sitemap constructions, is that it doesn't stop there, we need some
other sitemap constructions to make it really useful. And as said I feel
more for polishing the flowscript way, than being part of developing
alternative solutions. But you don't need my blessing for discussing and
developing such things if you feel a need for it.
My girlfriend tells me that sometimes it seems like I argue for the sake
of arguing.., that I would take the other side no matter what... and
that in a single conversation I might argue about why something is black
and then argue about the same thing is white once I change the other
person's opinion.
I know I do that... and the reason why I do that is that I force people
to convince themselves before convincing me. There is no such thing as
being right or wrong especially if we don't understand what we
really want in the first place.
I think that as long as cocoon grows incrementally and organically,
there is no problem in any approach and that usage will tell us if
something was a good idea or a bad one.
So, to cut it short: it really doesn't matter what you are saying but
*how much you are willing to suffer to get it across* :-)
More than anything, I act as a filter. A pain in your butt. I play death
in a design chess game... where the community is what wins.
So, it doesn't really matter what you do or propose, but how and how
open is your mind when you do that. The sofware result will be shaped by
reality and usage anyway, and it will never be perfect because
perfection is never in living things (and open developped software is a
living organism) if not in their own existance.
--
Stefano.
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Le 26 janv. 05, à 02:11, Stefano Mazzocchi a écrit : My girlfriend tells me that sometimes it seems like I argue for the sake of arguing.., that I would take the other side no matter what... and that in a single conversation I might argue about why something is black and then argue about the same thing is white once I change the other person's opinion... phheeewww...anyone know where nominations for the Girl Friend Nobel Prize can be entered? ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Lazy mode and compiling classloader (was Re: FOM input modules)
Sylvain Wallez wrote: Reinhard Poetz wrote: Daniel Fagerstrom wrote: Reinhard Poetz wrote: After some experiments with the new compiling classloader stuff, I personally don't feel a need for a scripting action solution. But this highly depends on your skills. Interesting, do you mean that you write ordinary actions and use the compiling classloader on them? I tried it and it worked for me. Currently, *you* have to make sure that the sitemap reloads (e.g. adding a space character) but if I understood Sylvain's mail to his lazy mode implementation correctly, this will help to get rid of this (ugly) workaround. Ahem, no: the lazy mode only loads (and therefore compiles) components the first time they are looked up in the service manager. That means that currently you have to touch the sitemap in order for classes to be reloaded. But the actual purpose of the lazy mode is not only fast startup time, but also fast *reload* time: the idea is that when a source file is changed, Cocoon is restarted in the same way as a ?cocoon-reload=true, therefore recompiling everything that needs to be recompiled and garbaging all instances of the previous versions of recompiled classes. But that reloading isn't there yet. Thank you, that's much clearer than my explanation (though I meant the same ;-) -- Reinhard
Re: Lazy mode and compiling classloader (was Re: FOM input modules)
Reinhard Poetz wrote:
Thank you, that's much clearer than my explanation (though I meant the
same ;-)
LOL!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: sitemap, jx and flow design (was: servicemanager and jxtg)
Daniel Fagerstrom wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
generate type=jx src=..
parameter name=userprofile dom={cocoon:/userprofile}/
...
/generate
You could do it from a flowscript, whats the problem with that?
Wait. You can do a lot of things with flow, but I also think that we
should not forget about what we already have.
The sitemap already contains input modules and as much as I was not
thrilled by them, I came to agree that sometimes they are very useful,
because while flow is great for stateful content, using it for
stateless dispatching looks really like a waste and I think we are
pushing flow so much that people will start to abuse it as a
procedural dispatch mechanism.
What you are asking and what Éric is asking are two different things:
he is asking to allow better integration between sitemap and data
generation and you are telling him that thou shall use flow.
Seem to me like we have switched opinion with each other ;)
You know, over the last few years I have written tons of RTs describing
more or less cool pipeline constructions for simplifying webapp
development. And you have after more or less convincing argumentation
stated: thou shall use flow and concluded with your obligatory -1.
My current interest is polishing the basic building blocks for building
webapps: JXTG, flow, CForms and maybe some more stuff so that it becomes
as coherent and smooth as possible and in some cases less monolithic.
Having such a gool I am more interested in seeing the usual I don't
want to use flow because of X for something that seem close to the
concern area for flow, as a good reason for discussing how to polish
flow so that it fullfills its task better.
Maybe handling data types other than strings; DOM, Java Beans, SQL
rowsets etc in the sitemap is an excelent idea. But my gut feeling,
after having spend considerable time thinking about building webapps
with sitemap constructions, is that it doesn't stop there, we need some
other sitemap constructions to make it really useful.
I tend to agree with you Daniel. I don't understand why we need datatype
declarations in the sitemap, but maybe a stronger contract between sitemap and
template makes sense.
Let's make a step back and let's define the usecase that makes us discuss the
border between flow and sitemap. IIUC it's about making objects available in
templates without having to go the detour of using flow _and_ defining a
stronger contract for this.
Two days ago, I wrote about my usecase for chained input modules. Daniel
answered, that in his opinion this looks like voodoo and suggested to have a
global action that is executed for every request. Wouldn't this be the solution
for passing objects to the view layer either?
Currently JXTG gives access to the session, the request and the application
context. So using them as container is possible today. The drawback: The
contract isn't defined very well because in your template you have to to
something like this:
p${cocoon.request.getAttribute('xyz')}/p
A weak contract IMO.
Having a strong contract like
generate type=jx src=..
parameter name=userprofile
object={$cocoon.request.getAttribute('userprofile')}/
/generate
could help us to make templates more side-effect free because then we could
forbid the direct access of the request and the session from within templates:
page xmlns:jx=...
p{$userprofile.getName()}/p
/page
We could even go a step further and enforce explicit variable declaration:
page xmlns:jx=...
jx:variable name=userprofile/
p{$userprofile.getName()}/p
/page
Unfortunatly those templates wouldn't still be side-effect free, because nobody
prevents me from doing
p{$userprofile.getRole().setName('newRoleName')}/p
And as said I feel
more for polishing the flowscript way, than being part of developing
alternative solutions.
Maybe you can comment on my response all the same :-)
But you don't need my blessing for discussing and
developing such things if you feel a need for it.
/Daniel
--
Reinhard
