Re: [RT] Improving Sitemap and Flowscript
On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:
Stefano Mazzocchi wrote:
Virtual Pipeline Components
---
snip what=suggestions I agree with/
I'm all in favour of this since the topic came up first. Unfortunatly,
I haven't found the time investigating an implementation but I believe
this should be straight forward.
Although we're not (yet) discussing implementation details, I would
like to suggest to wrap those pipeline fragments as Avalon components.
I believe this will become handy with blocks as we only need to expose
components from a block
Moving Sitemap components into cocoon.xconf
---
the default sitemap is too verbose and this scares people away. I
would like to move the default sitemap component definitions into the
cocoon.xconf.
Note that with blocks, the definitions of those components will be in
the block.xconf as well and this will be aggregated by the block
manager.
We had this already at some time. Cutting the complexity is good.
Perhaps we should follow the idea of splitting cocoon.xconf and root
sitemap.xmap into two files each, one for the defaults and one (empty)
for customization.
Pluggable Request Factories
---
snip/
OK
Interception in Flowscript
While writing flowscripts, you realize how many things can be applied
to many of the various flowscript functions that are called by the
sitemap. In Linotype, I ended up using the ability that javascript
gives you of using functions as native objects and then invoquing
them by passing a modified argument vector.
It came to me that what I did with linotype was a really-poor-man
interception mechanism. Interception is the ability to intercept a
method call and execute some code before or after the execution of
the intercepted method.
Interception is the simplest form of the aspect orientation.
Adding interception mechanism to the flowscript requires three
changes, two in the FOM, one (more important!) in the javascript
syntax:
1) the addition of a function call to the cocoon object, which
indicates that intercepting function calls should be imported.
cocoon.apply(blah.js);
where blah.js contains the intercepting functions.
2) the addition of a function call to context that continues the
intercepted invocation:
...
continueExecution(arguments);
...
3) the introduction of wildcars for function names.
function get*() {
...
}
the above seems rather accademic, so allow me to write an example
where the use of aspect-oriented flowscript would shine.
Something that can be modelled very well as an aspect is
authentication/authorization (aka login) because it's not something
that is part of the webapp (at least, it shouldn't be!) but it's
something that is wrapped around it to allow people to access it
without the proper authorization.
Here I like to disagree, sort of. While I agree that authentication is
a good use case for AOP, I don't come to the same conclusion. In fact,
by using an action to protect a complete URI space very much the same
can be achieved.
true
I know, actions are not liked by everyone, but this is one of the best
applications for them.
are you suggesting we don't think about adding interception in flow
because otherwise this would kill the only place where actions have a
reason to exist?
So, please provide a more convincing use case for the introduction of
AOP in Cocoon ;-)
Actions can be used as interceptors. It's not their only ability, but
yes, it's possible and good actions do perform this way.
So, any use case that requires action-based interception, will work as
nicely with flow interception.
What would we gain?
1) action-based interception is a concern of the flow layer, not of the
pipeline definition. i will never stop saying this, but actions should
not exist in the sitemap realm, since they mix concerns.
2) actions have a terribly poor error handling capability, even when
used as interceptors, flow-based interception keeps all the
functionality available at the flow level.
3) actions are hardcoded in the sitemap pipelines definitions.
flow-based interception will allow to wrap existing code without
needing to modify it or it will be possible to remove or modify
interception without modifying the original flow code.
I'll think about more juicy use cases tonight.
--
Stefano.
DO NOT REPLY [Bug 22648] - minor typo in src / javadocs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22648. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22648 minor typo in src / javadocs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 22526] - FOM cocoon.request.getCookies()'s cookies can't be read
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22526. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22526 FOM cocoon.request.getCookies()'s cookies can't be read --- Additional Comments From [EMAIL PROTECTED] 2003-08-22 10:00 --- Created an attachment (id=7919) same patch as before, added the npe fix.
Re: Production build for Cocoon?
On Friday, Aug 22, 2003, at 18:05 Europe/Rome, Roger I Martin PhD wrote: For Cocoon developers: you need to start thinking of Cocoon as a servlet intended to be used inside of your customer's webapp. For Roger I Martin PhD: you need to start reading the mail list archives (or ask) before attempting to read our minds using the released software as a starting point. It helps a lot to reduce the chance of look like a pretencious ignorant. If I opened an M$ product out of the box and the way to INSTALL it was described as in INSTALL.txt with the results far from That's it! I would not hesitate to return it. In case, we'd immediately refund you and give your money back. Oh, no, wait, we are so efficient that you can find your money attached below. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote: Interesting,didn't know that, thought to have been in Darmstadt ;-) I know, actions are not liked by everyone, but this is one of the best applications for them. are you suggesting we don't think about adding interception in flow because otherwise this would kill the only place where actions have a reason to exist? I'm going to ignore this comment. So, please provide a more convincing use case for the introduction of AOP in Cocoon ;-) Actions can be used as interceptors. It's not their only ability, but yes, it's possible and good actions do perform this way. So, any use case that requires action-based interception, will work as nicely with flow interception. What would we gain? 1) action-based interception is a concern of the flow layer, not of the pipeline definition. i will never stop saying this, but actions should not exist in the sitemap realm, since they mix concerns. Well, probably yes. Although with very little organization, SoC can be achieved for this use case. But in general, you are right. 2) actions have a terribly poor error handling capability, even when used as interceptors, flow-based interception keeps all the functionality available at the flow level. Right, one can easily start a complex flow as error handling. 3) actions are hardcoded in the sitemap pipelines definitions. flow-based interception will allow to wrap existing code without needing to modify it or it will be possible to remove or modify interception without modifying the original flow code. Absolutely. I don't want to argue about AOP in general. It's just that your example is only touching the concept and for this we already have a solution. This solution is not as elegant as AOP but it's here and it's usable. We have some other features we all agree are really needed i.e. blocks. I'm not at all against AOP in Rhino. I just would like us to be more focussed on Cocoon, that's all ;-) I'll think about more juicy use cases tonight. Great! Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
RE: [RT] Improving Sitemap and Flowscript
From: Christian Haul I'll think about more juicy use cases tonight. Great! ... and here some thoughts from an AOP beginner ;) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106153567628087w=2 Reinhard
Re: accessing sitemap parameters in a flow script
Marc Portier wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip /
If we match by variable name rather than by position, it would work
anyway.
... but I have the feeling I'm missing a big point here.
Yeah : the point is that parameters are passed as Object[] to a JS
function. The names given both in the sitemap parameters and the JS
function parameters are therefore unusable for parameter passing.
Only their position counts. See
FOM_JavaScriptInterpreter.callFunction (line 553) : funArgs is a
Object[].
Sylvain
Yes,
and it's quite logic since js doesn't have the notion of named
argument-passing in the first place:
what I mean is that you can't have a
function whatever( x, y) {
return x - y;
}
and then call that with:
someresult = whatever(y= 4, x= 5)
while naming the arguments by how they are declared in the function,
and not deducing their role from their position
there are some scripting languages that do this IIRC, but not js
Going back to the origin of the discussion: we are calling this NOT
from another js code portion, but from our beloved sitemap and there
it is hard to see functional difference between
map:call function=whatever
map:parameter name=x value=5 /
map:parameter name=y value=4 /
/map:call
and
map:call function=whatever
map:parameter name=y value=4 /
map:parameter name=x value=5 /
/map:call
(although in strict XML infoset speak I guess there is a difference,
no? (order of elements is important)
maybe it is just that other spots in the sitemap made us custom to
ignoring this fact?)
One way to go about balancing of the technics and the sociologics in
this could be to pass in an argument-object-map rather then multiple
arguments:
so thinking about this:
function whatever(args) {
dosomething(args.x);
dosomething(args.y);
}
we get a more natural comparison between:
someresult = whatever({y: 5, x: 4})
and:
map:call function=whatever
map:arguments
map:parameter name=y value=5 /
map:parameter name=x value=4 /
/map:arguments
/map:call
which the famous line 553 Sylvain just mentioned could easily map onto
a single element Object[] to pass...
but all I did now is made some stuff more explicit...
what do you guys think, some direction for a suitable compromise?
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote: I know, actions are not liked by everyone, but this is one of the best applications for them. are you suggesting we don't think about adding interception in flow because otherwise this would kill the only place where actions have a reason to exist? So, please provide a more convincing use case for the introduction of AOP in Cocoon ;-) Yawn... ;-) I still believe authentication code should be orthogonal to actual application logic, and rather be defined by the container. In this discussion, I think 'sitemap' == 'container'. Also, since authentication-requiring realms are a part of the overall URI namespace, when finding out which parts need authentication, I would check first with the container (web.xml) - sitemap.xmap - flowscript. Not making authentication handling part of your application is one of the first things I learned over here, when greeting Giacomo at ApacheCon in London. So, if you guys are talking about authentication with actions vs flowscript interceptors, what are you talking about: doing the authentication, or checking authorization? I'm curious and want to understand better. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
DO NOT REPLY [Bug 22648] - minor typo in src / javadocs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22648. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22648 minor typo in src / javadocs --- Additional Comments From [EMAIL PROTECTED] 2003-08-22 04:21 --- Created an attachment (id=7918) diff to Processor.java
Re: Woody, maps, and repeaters
Hugo Burm wrote:
Hello Marc,
sorry for the late reply...
Ok. Let me explain. Maps are sometimes much more convenient than Lists
(let's skip a discussion on that one). So I have two classes:
public class HContact {
private String id;
private String firstName;
private String lastName;
private String phone;
private String email;
skipgetter/setter methods /skip
}
public class HForm2Bean {
private String email;
private String phoneCountry;
private String phoneZone;
private String phoneNumber;
private String ipAddress;
private Date birthday;
private int aNumber;
private Map contacts = new HashMap();
skipgetter/setter methods /skip
}
These classes are identical to the Woody examples apart from one line in
(H)Form2Bean:
Woody Sample:private Collection contacts = new ArrayList();
Well, for what its worth the not to have discussion is probably
not on LIST vs MAP but MAP vs SET :-)
I'ld personally would have tackled this with a HashSet of
contacts and adding the appropriate hashcode() and equals()
methods to the HContact so its very own id would serve as the
fast lookup in the Set...
(but it doesn't really change much the real issue here)
What I want to do is: create a Map of contacts in HForm2Bean and access
these contacts with a key id.
This key is also stored in one of the fields of HContact (id). The field
that is the key, should be one of the configuration parameters of the Woody
repeater.
yep.
This solves your question which key to use?.
not really, it doesn't solve the question on the way back, unless
you expect the id's to be edited by hand?
(which would surely require another RepeaterBinding implementation)
So what I need is a Woody Form to edit these beans. As you have found out, I
dived into this problem myself. But your company knows a lot more about the
Woody internals than I do.
our goal is to achieve the opposite for sure
About your explanation of LIST vesus MAP: Thanks. But I am not convinced.
it's just the technique I use to understand how jxpath is looking
at stuff
When I change your function function form2bean(form) in the Woody sample
(just for completeness: it isn't mine)
file binding_example.js in such a way that a bean and a number of contacts
are created; the editing is skipped; and we go directly to your pipeline
form2bean-success-pipeline, the form2_jx.xml form is called. This contains
the loop:
jx:forEach var=item items=${form2bean.contacts}
tr
td${item.id}/td
td${item.firstName}/td
td${item.lastName}/td
skip/
/tr
/jx:forEach
This loops shows the correct results when I use a map instead of a list!
hm, my turn to be not convinced: above uses the ${..} expressions
inside jx and not the #{..}
${..} in jx are evaluated by jexl
#{..} are covered by jxpath
so we're looking at a horse of an entirely different color here.
the binding files are using jxpath, and as far as I can see those
would need a different notation for maps vs lists
I think this could never happen if your XML layout for a map representation,
shown below, is correct.
myBean
address
hugostreet/city//hugo
marcstreet/city//marc
brunostreet/city//bruno
/address
/myBean
Or translated to the contacts example:
myBean
contacts
id1id/firstname/lastname//id1
id2id/firstname/lastname//id2
id3id/firstname/lastname//id3
/contacts
/myBean
When I read your second (oops) email, the map iteration path is now
identical to the list iteration path. But how can the jx:foreach loop skip
the extra level (the key, e.g. hugo, marc, or id1,id2 etc) of the
iterated items?
as above: it uses jexl
my xml-view of things only helps to write down the (j)xpath
expressions
Sorry for pinpointing on this jxpath syntax, but a number of people on this
list have spent hours trying with some kind of trial-and-error method to
find out how these beans and relations are mapped to XML by jxpath (I am one
of them). So any comment that makes this issue more clear is appreciated.
well, the first confusion to get rid off is the $ versus # :-)
only when you get into the # you have to think about how to get
the jxpath right
(first help there is of course the jxpath website, secondly and
just for me this 'look-as-xml' technique has helped quite often)
Back to your issue: how to edit these beans with Woody/Binding?
I would need some more time to get into it more deeply, so I
wouldn't mind if somebody with more current slack hacks this up
ans shares this
Hugo, how urgent is this for you?
AFAICS this needs a different RepeaterBinding of some sort that
is not that much different to the existing one, just that
1/ the current logic for deciding if the row was new, removed or
updated will need to change, and I'll be assuming that the new
id's are entered manually (probably removing all and rebuilding
all is the easier strategy here)
2/ it shouldn't
Re: accessing sitemap parameters in a flow script
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
snip /
If we match by variable name rather than by position, it would work
anyway.
... but I have the feeling I'm missing a big point here.
Yeah : the point is that parameters are passed as Object[] to a JS
function. The names given both in the sitemap parameters and the JS
function parameters are therefore unusable for parameter passing.
Only their position counts. See
FOM_JavaScriptInterpreter.callFunction (line 553) : funArgs is a
Object[].
Sylvain
Yes,
and it's quite logic since js doesn't have the notion of named
argument-passing in the first place:
what I mean is that you can't have a
function whatever( x, y) {
return x - y;
}
and then call that with:
someresult = whatever(y= 4, x= 5)
while naming the arguments by how they are declared in the function,
and not deducing their role from their position
there are some scripting languages that do this IIRC, but not js
Going back to the origin of the discussion: we are calling this NOT
from another js code portion, but from our beloved sitemap and there
it is hard to see functional difference between
map:call function=whatever
map:parameter name=x value=5 /
map:parameter name=y value=4 /
/map:call
and
map:call function=whatever
map:parameter name=y value=4 /
map:parameter name=x value=5 /
/map:call
(although in strict XML infoset speak I guess there is a difference,
no? (order of elements is important)
maybe it is just that other spots in the sitemap made us custom to
ignoring this fact?)
One way to go about balancing of the technics and the sociologics in
this could be to pass in an argument-object-map rather then multiple
arguments:
so thinking about this:
function whatever(args) {
dosomething(args.x);
dosomething(args.y);
}
we get a more natural comparison between:
someresult = whatever({y: 5, x: 4})
and:
map:call function=whatever
map:arguments
map:parameter name=y value=5 /
map:parameter name=x value=4 /
/map:arguments
/map:call
which the famous line 553 Sylvain just mentioned could easily map onto
a single element Object[] to pass...
but all I did now is made some stuff more explicit...
what do you guys think, some direction for a suitable compromise?
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
Sylvain
yep,
that crossed my mind,
but that knowledge didn't seem to stop the discussion in this
thread before :-)
so I was just going for a more explicit approach that maybe
did I have to agree that it adds to no functionality
it could make things however less arbitrary/hidden
cocoon.parameter?, or did we use cocoon.function-arguments
or was it on another object in the FOM? let's send a mail!
Subject: Who remembers actively where those damn parameters are?
IMHO at this stage the thread is not any more about 'what can be
functionally done' it is about 'how can we make it self
describing' so we don't end up explaining this to people all over
again?
in any case, it was just a proposal, and if nothing else, I hope
I pointed out the source-mismatch in this.
regards,
-marc=
PS: I'ld like to understand how cocoon.parameters gets to exist
since that is maybe something I coud use inside Apples as well
(you know by heart where to look?)
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino wrote: Looks like I missed some serious fun during these vacations... time to catch up! Stefano Mazzocchi wrote: Virtual Pipeline Components --- Love the idea. Even because it was me suggesting something like that a couple of years ago and being blamed of FS... ;-) Really? any pointer? (I'm not being sarcastic, but curious... if I judged FS something that I later ended up proposing, there is something wrong in my FS meter ;-) Sorry, no pointers, just witnesses if they remind the live discussion who took place one day in Bibop.:-) We were still using the compiled sitemap and I was suggesting how components could have been aggregated (G-T* / T* /T*-S) as macros to be unrolled by XSLT. You came up with FS bells and problems with parameter resolving, so the discussion was kinda over. I will be more stubborn next time. ;-) Pluggable Request Factories --- 2. Are you sure that adapting the request is enough? I couldn't come up with anything that required more than that. I'd say that the different use cases you're pointing out require a bit more then just the request object: I'd say that the whole environment might need a particular treatment in most cases. Why so, can you elaborate? maybe with a specific example? scenarios help the design. You might need to have access to the response too. In WebDAV world, as an example, you need to set a whole bunch of headers (Allow:, DAV:, MS-Author-Via - yuck - and more), and a DASL component needs to specify the search vocabularies supported. True, you can do it by hand, but it would be much better if such manipulation could be done by a request-factory. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Improving Sitemap and Flowscript
On Saturday, Aug 23, 2003, at 08:45 Europe/Rome, Jay Freeman ((saurik)) wrote: Stefano: Could you describe what you mean by above and sideways? :) I'm not sure what you are seeing, hehe. To me the super-sitemap (which is kind of what this would be, as the main sitemap would be a subsitemap of it) is above the sitemap, and cocoon.xconf is relatively unrelated and is therefor sideways from the sitemap. Also, to me at least there seems to be more of a hackish feeling in having to different ways to setup components, one using xconf semantics, and one using sitemap semantics. I'd rather have the base.xmap one where you can have an extra file of just component definitions from a sitemap that are overridden by the sitemap itself rather than putting that same thing in the xconf... at least the layout of the file would be the same (but that still seems hackish in the sense that this extra feature was added to support what's pretty much a limited super-sitemap). Ok, here is what I think it would be wise to do: 1) leave cocoon.xconf as is 2) allow the sitemap to get components configurations from an external file or from an inside definition (as today). 3) write our main sitemap pointing to its components to an external file. The proposed sitemap syntax is something like map:sitemap map:components src=blah.xconf/ map:pipelines ... /map:pipelines /map:sitemap In case, both src= and internal components are defined, these overload the ones included in the file. How does this sound? -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Saturday, Aug 23, 2003, at 14:17 Europe/Rome, Steven Noels wrote: I still believe authentication code should be orthogonal to actual application logic, and rather be defined by the container. Sure, too bad everybody has a different opinion on what the container is. If you talk to os kernel folks, they think authentication should happen right at TCP/IP stack level, if you talk to httpd, they will give you an apache module, if you talk to servlet engine folks, they will give you a web.xml descriptor or, if you are lucky, a servlet filter, if you talk to sitemap lovers, they will give you an action. And all of them will think they are doing it right and the one above them are just asking for trouble. In this discussion, I think 'sitemap' == 'container'. Also, since authentication-requiring realms are a part of the overall URI namespace, when finding out which parts need authentication, I would check first with the container (web.xml) - sitemap.xmap - flowscript. well, follow the entire chain and you'll get down to IPSEC. In fact, in media stat virtus (balance is in the middle, for the latin unsavy) and complex authentication/authorization schemes may well require several progressively refined steps, each happening in their own realm. So, it might be useful to use a firewall at the kernel level to avoid DoS, then HTTPd SSL authentication and tunneling (in the web server for performance and scalability), then app-level authorization based on the SSL parameters passed on. Not making authentication handling part of your application is one of the first things I learned over here, when greeting Giacomo at ApacheCon in London. So, if you guys are talking about authentication with actions vs flowscript interceptors, what are you talking about: doing the authentication, or checking authorization? In the example I made, both authentication and authorization were done in the same interceptor (well, the authentication stage was handled by an external polymorphic component). -- Stefano.
Re: 'Production' build for Cocoon?
Hi Roger: Can you write the intro as you suggested? Please don't take this question in the bad sense. I think all of us can help to make a better Cocoon. We are a community with a common interest called Cocoon framework. I meet Cocoon a year ago (I still consider my self a newbie in Cocoon). From my point of view, there has been an amazing improvement in the Cocoon documentation: Currently, we have 3 printed books released in less than a year, a nice (still growing) wiki site with many info and helps docs to read and at the end but not the last important a better official cocoon documentation. A year ago there was nothing like that, just some docs in the official cocoon site and a handfull articles somewhere in the vast Internet. It is really amazing how long the project growed in the last year. I saw that. Well, as usual, nothing is perfect and because of that we are still working to improve Cocoon framework every day. I encourage you to join us an helps in this wonderful project. From my own experience in the project I learned that: Critics are always welcomed, because helps to improve the framework. But solutions are better welcomed. By solutions I mean a patch that address a particular problem someone see. Remember that this is a multi cultural community that try to use a unique language (english). The skill of written english that members use is very diferent. From totally beginners to people with great skill to write english. This is a fact. Take my own example: To write this mail I need more than 30 mins. I need to review what I wrote to make sure if my message carries what I mean and I know still there are many errors and sometimes after my own review my message is not carried in the lines. But is is not because I am a stupid, this is because simply my mother language is not english. For there reasons, I think we need people with better skill of written english to help us to write and improve the docs. And if this is your case I encourage you to helps us to write your requested INSTALL.txt :) As usual, when there is nothing, the first draft or the first block of the construction is hard to put, after that when we have something then improve it is easier! Please try to write the first draft. :) At the end I want to write a phrase from a song from Pink Floyd: Together we stand, divided we fall :) Best Regards, Antonio Gallardo P.S: I dont want to fight with nobody here and I am not trying to attack nobody. Please take my message in the most good sense. Really we need to work together :)
RE: Woody, maps, and repeaters
Marc Portier wrote:
Hugo Burm wrote:
Hello Marc,
sorry for the late reply...
Ok. Let me explain. Maps are sometimes much more convenient than Lists
(let's skip a discussion on that one). So I have two classes:
SKIP/
Well, for what its worth the not to have discussion is probably
not on LIST vs MAP but MAP vs SET :-)
I'ld personally would have tackled this with a HashSet of
contacts and adding the appropriate hashcode() and equals()
methods to the HContact so its very own id would serve as the
fast lookup in the Set...
(but it doesn't really change much the real issue here)
What I want to do is: create a Map of contacts in HForm2Bean and access
these contacts with a key id.
This key is also stored in one of the fields of HContact (id). The field
that is the key, should be one of the configuration parameters
of the Woody
repeater.
yep.
This solves your question which key to use?.
not really, it doesn't solve the question on the way back, unless
you expect the id's to be edited by hand?
(which would surely require another RepeaterBinding implementation)
I tried to ommit the persistence topic, but many of the issues above have to
do with the Hibernate framework I am using. E.g. the id is generated by
Hibernate. This works OK for the list implementation in Woody. The Woody
framework detects a contact that is inserted because its id is null. Then,
Hibernate generates the id when saving the contact to hard disk.
About lists, maps, and sets: Hibernate has four mappings: the three I just
mentioned, plus something called a bag. So people like me will keep on
asking for repeaters for these three types. JDO 2.0 builds on Hibernate. So
I will not be the last one asking for this.
file binding_example.js in such a way that a bean and a
number of contacts
are created; the editing is skipped; and we go directly to your pipeline
form2bean-success-pipeline, the form2_jx.xml form is called.
This contains
the loop:
jx:forEach var=item items=${form2bean.contacts}
tr
td${item.id}/td
td${item.firstName}/td
td${item.lastName}/td
skip/
/tr
/jx:forEach
This loops shows the correct results when I use a map instead of a list!
hm, my turn to be not convinced: above uses the ${..} expressions
inside jx and not the #{..}
${..} in jx are evaluated by jexl
#{..} are covered by jxpath
so we're looking at a horse of an entirely different color here.
OK, may be I had too much sunshine the last couple of weeks. I did a post
myself about the difference between # and $ a few weeks ago which covered
exactly this problem:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106050576128633w=2
I checked the JXPath docs and your explanation appears to be correct. Sorry.
Back to your issue: how to edit these beans with Woody/Binding?
I would need some more time to get into it more deeply, so I
wouldn't mind if somebody with more current slack hacks this up
ans shares this
Hugo, how urgent is this for you?
AFAICS this needs a different RepeaterBinding of some sort that
is not that much different to the existing one, just that
I hacked the Woody RepeaterBinding myself and solved my own urgent problem.
Listing a map of contacts is working. Updating is working. Adding and
deleting contacts is something I don't need at the moment (off course my
real world problem has nothing to do with this form2bean and contact
classes), but I will try to add this, and send the results to you.
Thanks.
Hugo Burm
Re: [RT] Improving Sitemap and Flowscript
Stefano: This actually gives me a feeling of defining components below the sitemap, lol. I think it's a good solution, though :). It definitly solves both my deployment of application issues and the whole complicated looking sitemap problem. Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 8:51 AM Subject: Re: [RT] Improving Sitemap and Flowscript ... Ok, here is what I think it would be wise to do: 1) leave cocoon.xconf as is 2) allow the sitemap to get components configurations from an external file or from an inside definition (as today). 3) write our main sitemap pointing to its components to an external file. The proposed sitemap syntax is something like map:sitemap map:components src=blah.xconf/ map:pipelines ... /map:pipelines /map:sitemap In case, both src= and internal components are defined, these overload the ones included in the file. How does this sound? -- Stefano.
Re: accessing sitemap parameters in a flow script
Marc Portier wrote:
snip/
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
And nobody still answered the question: why passing of parameters into
the function
function whatever(x, y, z)
is required and can not be removed? Let's remove this and move along.
cocoon.parameters is much better and has no place for confusion.
Vadim
Re: Woody, maps, and repeaters
Hugo Burm wrote:
Marc Portier wrote:
Hugo Burm wrote:
Hello Marc,
sorry for the late reply...
Ok. Let me explain. Maps are sometimes much more convenient than Lists
(let's skip a discussion on that one). So I have two classes:
SKIP/
Well, for what its worth the not to have discussion is probably
not on LIST vs MAP but MAP vs SET :-)
I'ld personally would have tackled this with a HashSet of
contacts and adding the appropriate hashcode() and equals()
methods to the HContact so its very own id would serve as the
fast lookup in the Set...
(but it doesn't really change much the real issue here)
What I want to do is: create a Map of contacts in HForm2Bean and access
these contacts with a key id.
This key is also stored in one of the fields of HContact (id). The field
that is the key, should be one of the configuration parameters
of the Woody
repeater.
yep.
This solves your question which key to use?.
not really, it doesn't solve the question on the way back, unless
you expect the id's to be edited by hand?
(which would surely require another RepeaterBinding implementation)
I tried to ommit the persistence topic, but many of the issues above have to
do with the Hibernate framework I am using. E.g. the id is generated by
Hibernate. This works OK for the list implementation in Woody. The Woody
framework detects a contact that is inserted because its id is null. Then,
Hibernate generates the id when saving the contact to hard disk.
About lists, maps, and sets: Hibernate has four mappings: the three I just
mentioned, plus something called a bag. So people like me will keep on
asking for repeaters for these three types. JDO 2.0 builds on Hibernate. So
I will not be the last one asking for this.
sure, and sorry if I ever gave you the impression that you were
asking for 'bad' or useless things... I highly welcome any use
case that shows an itch to scratch... at the time I just wanted
some more clarification
thx for explaining the id generation thing, it adds to the food
for thought on this
file binding_example.js in such a way that a bean and a
number of contacts
are created; the editing is skipped; and we go directly to your pipeline
form2bean-success-pipeline, the form2_jx.xml form is called.
This contains
the loop:
jx:forEach var=item items=${form2bean.contacts}
tr
td${item.id}/td
td${item.firstName}/td
td${item.lastName}/td
skip/
/tr
/jx:forEach
This loops shows the correct results when I use a map instead of a list!
hm, my turn to be not convinced: above uses the ${..} expressions
inside jx and not the #{..}
${..} in jx are evaluated by jexl
#{..} are covered by jxpath
so we're looking at a horse of an entirely different color here.
OK, may be I had too much sunshine the last couple of weeks. I did a post
myself about the difference between # and $ a few weeks ago which covered
exactly this problem:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106050576128633w=2
I checked the JXPath docs and your explanation appears to be correct. Sorry.
no need to appologise, this confuses me all the time, in fact you
had me doubthing my little technique for a while... so spotting
the $# just gave me back some mental sanity :-)
Back to your issue: how to edit these beans with Woody/Binding?
I would need some more time to get into it more deeply, so I
wouldn't mind if somebody with more current slack hacks this up
ans shares this
Hugo, how urgent is this for you?
AFAICS this needs a different RepeaterBinding of some sort that
is not that much different to the existing one, just that
I hacked the Woody RepeaterBinding myself and solved my own urgent problem.
Listing a map of contacts is working. Updating is working. Adding and
deleting contacts is something I don't need at the moment (off course my
real world problem has nothing to do with this form2bean and contact
classes), but I will try to add this, and send the results to you.
thx chap, would surely like to see it, if you could hack it up as
a an extra woody-sample (damn: there goes the hibernate-licensing
issue again) that would be really great
you got this up on my todo list, if I reach this before you got
the time to pollish up I might be asking for just sending what
you have at the time, if you don't mind
Thanks.
Hugo Burm
regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
