Re: Writing for users (was: Re: [RT] Improving Sitemap and Flowscript)
Hunsberger, Peter wrote: Now-a-days I think anyone that has done even a bit of Web programming has been exposed to some form of Object Model. Microsoft refers to them in their DHTML documentation, then you've got all the various DOMs hanging around. Microsoft isn't actually my official reference. :-) I have the perception that environment is more generic than object model, but probably both me and you are too biased. We should ask managers. :-) You've pretty well gotta have some comfort with OO terms if you're touching Cocoon... I have to strongly disagree here. Please point me to an example of OO skills needed to manage a sitemap (*not* develop Cocoon components): if there are, we are doing something wrong and the just failed to build the pyramid envisioned a long time ago. You need to know XML, granted, but I see no real need of OO background. Even managers need some basic understanding of OO if they are going to manage their staff effectively. Given that they shouldn't really care one of their staff is adapting an environment or an object mode I'd vote for object model. Environment actually sounds harder to explain to the managers I know. Remember that in this case manager != CTO. A sitemap manager is just someone managing the URI space and building pipelines. And to me it's quite the opposite: most (sitemap) managers I know would understand environment much better, since it's not context specific. 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: Writing for users (was: Re: [RT] Improving Sitemap and Flowscript)
Gianugo Rabellino [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Now-a-days I think anyone that has done even a bit of Web programming has been exposed to some form of Object Model. Microsoft refers to them in their DHTML documentation, then you've got all the various DOMs hanging around. Microsoft isn't actually my official reference. :-) I have the perception that environment is more generic than object model, but probably both me and you are too biased. We should ask managers. :-) Fair enough... You've pretty well gotta have some comfort with OO terms if you're touching Cocoon... I have to strongly disagree here. Please point me to an example of OO skills needed to manage a sitemap (*not* develop Cocoon components): if there are, we are doing something wrong and the just failed to build the pyramid envisioned a long time ago. You need to know XML, granted, but I see no real need of OO background. Ok, let me rephrase that: you've pretty well gotta have some comfort with OO terms if you're touching the Web these days... Even managers need some basic understanding of OO if they are going to manage their staff effectively. Given that they shouldn't really care one of their staff is adapting an environment or an object mode I'd vote for object model. Environment actually sounds harder to explain to the managers I know. Remember that in this case manager != CTO. A sitemap manager is just someone managing the URI space and building pipelines. And to me it's quite the opposite: most (sitemap) managers I know would understand environment much better, since it's not context specific. What's an environment? Seriously: if I tell my manager I've to modify an object model he's going to more or less understand. If I tell him I've got to modify an environment he'll think I'm talking about Windows level variables and wonder a) why it takes any time at all, and b) why doesn't Cocoon have a better way of being configured, like that big XML file we occasionally talk about. Then he'll be really mystified if I have to explain to him that some coding is required. OTOH, this is a mostly Windows shop, so your mileage may vary...
Writing for users (was: Re: [RT] Improving Sitemap and Flowscript)
Sylvain Wallez wrote: 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. Damn, great point. So, back one step: could adapt-environment help? or is environment not good enough for people to understand? What do others think? Mmmh... Up to now, the environment is mostly non visible to regular components (i.e. out of the sitemap/pipeline machinery). Exposing it may lead to many abuses and misuses. I would go back only a half-step : adapt-object-model sounds better as it provides all that it needed for Gianugo's use cases, and avoids messing up the environment. I'm fine with the concept, but this brings another question: who is the average sitemap writer/manager? I would say that in the Cocoon management SoC paradigm who manages the sitemap is not necessariyl an OO programmer (or, for that matter, a programmer altogether). She is (probably) knows about XML, HTML and HTTP, but it's far less than granted that he knows what an object model is. I think, then, that sitemap semantics should not assume previous OOP knowledge, and I would refrain from using programmer-domain specific terms to describe the sitemap behaviour. This is why I'm more inclined towards environment: it's probably easier to explain to a programmer that sitemap's environment is actually the object model than having a manager understand what the heck an object model is. Thoughts? -- 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 Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote: Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent. I agree when you say that since the introduction of the cocoon: protocol, map:resource is now redundant (and less appealing, as well). In fact, we could go as far as saying that map:resource is no longer needed and could be deprecated. This would leave us only with pipelines, components and virtual components (which are, in fact, typed pipeline fragments), and the cocoon: protocol to mix them, if needed. What remains is the views part, that has introduced pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met IOW, I'm rephrasing, using different terminology, that a view is an orthogonal mechanism, that interacts with the normal sitemap using some metadata and an exit pipeline. The labels are effectively metadata, as they describe the pipeline. The exit pipelines, ie the views themselves, are what has to be done. Yes, views are orthogonal pipelines. (I won't use AOP terminology that I personally don't yet like) See, I don't like it too! ;-) well, when you propose something like map:aspects it seems AOP-ish enough for me ;-) that's not coherent with the above. So we can generalize it, and add configurability to the view mechanism to specify other conditions. Thus views effectively insert pipeline fragments at a certain condition. In fact they insert their contents after a label. So the label is the condition. I know it's a matter of terminology pickyness, but I disagree. The condition that triggers the view is the view request. The result of this condition is the execution of the pipeline that is 'instrumented' to route its output somewhere else (to the view, which can now be seen as a virtual serializer) *first proposal* I propose that we define other conditions. map:view name=content from-label=content map:serialize type=xml/ /map:view becomes: map:view name=content type=from-label test=content map:serialize type=xml/ /map:view This makes it possible to make a different position where to start from... What can also be made configurable is *when*, in which condition, it's triggered, but the logic has to be inverted. What I mean here is that views are triggered only by the user. Normal results are done *without* calling views. So if I want to say: insert a logger after each generator, I cannot do it easily, as I would have to call a logger-view for it to be called. And I would have only one possible insertion per pipeline, as only one view is called at a time. ok, now I get it Now we say: when the view is triggered, start at a label After it could be: when the view is triggered, start at position Instead we need: when the position is met, check if it has to be triggered. Here is an example that uses this inverted AOPish system for views. Let me rephrase this: the following is a way of defining views in a more generic way. Here I don't say anymore: when the user asks for a view trigger the label (or more generic as in the first proposal) condition, but at every stage check if a condition is met, and if so execute the generalized view. hm *second proposal* Make it possible to tell Cocoon to add pipeline snippets (ie virtual pipelines) given certain rules. This makes it possible to have views be made with this more generic mechanism. The following adds two aspects: - an aspect gets called from every content position and gathers links. - the other one gets called from every content position. If the request has a cocoon-view=links, then the links are serialized. map:aspects map:aspect type=from-label test=content !-- Any required link munging -- map:transformer type=gather-links/ /map:aspect map:aspect type=from-label test=content map:action type=request-param map:param name=cocoon-view value=link map:serializer type=links/ /map:action /map:aspect /map:aspects you are using AOP the micro-granular way. This is: remove crosscutting by making all overlapping aspect objects and compose them together. I tend to dislike this practice since it leads, IMHO, to poor readability (users don't have the vision of crosscutting concerns that we developers do, and they perceive it as unnecessary overcomponentization) a critic to the above is: why would you want to gather-links if you are not going to serialize them? You are suggesting that a more general aspect-oriented approach to pipeline composability might be general enough to allow views to be replaced by such a more powerful approach. I agree. What I don't understand is why we should give away a perfectly fine system for a new flexibility we don't need. [note how I avoided to named this FS even if I was very tempted to do so ;-)] This would make it very easy to add security-based
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote, On 28/08/2003 17.27: On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote: Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent. I agree when you say that since the introduction of the cocoon: protocol, map:resource is now redundant (and less appealing, as well). In fact, we could go as far as saying that map:resource is no longer needed and could be deprecated. This would leave us only with pipelines, components and virtual components (which are, in fact, typed pipeline fragments), and the cocoon: protocol to mix them, if needed. +1 from me for this ... (I won't use AOP terminology that I personally don't yet like) See, I don't like it too! ;-) well, when you propose something like map:aspects it seems AOP-ish enough for me ;-) that's not coherent with the above. Only the name aspect. I refrained talking about pointcuts, advises, etc... (ugh, I do hate those...) So we can generalize it, and add configurability to the view mechanism to specify other conditions. Thus views effectively insert pipeline fragments at a certain condition. In fact they insert their contents after a label. So the label is the condition. I know it's a matter of terminology pickyness, but I disagree. The condition that triggers the view is the view request. The result of this condition is the execution of the pipeline that is 'instrumented' to route its output somewhere else (to the view, which can now be seen as a virtual serializer) Correct. You know how messy I am in describing things. Put the right terminology instead of condition. ... you are using AOP the micro-granular way. This is: remove crosscutting by making all overlapping aspect objects and compose them together. I tend to dislike this practice since it leads, IMHO, to poor readability (users don't have the vision of crosscutting concerns that we developers do, and they perceive it as unnecessary overcomponentization) a critic to the above is: why would you want to gather-links if you are not going to serialize them? Yes, I've come to the same conclusion yesterday too. You are suggesting that a more general aspect-oriented approach to pipeline composability might be general enough to allow views to be replaced by such a more powerful approach. I agree. Ok. What I don't understand is why we should give away a perfectly fine system for a new flexibility we don't need. [note how I avoided to named this FS even if I was very tempted to do so ;-)] ;-) Yes, I see this too now. The RT started out of a link-gathering evolution, and for that only it may be too much... This would make it very easy to add security-based checks, logging, or any other stuff. map:aspects map:aspect type=pipeline test=start map:action type=check-security/ /map:aspect map:aspect type=pipeline test=all map:transformer type=logger/ /map:aspect map:aspect type=error test=all map:action type=notify-admin/ /map:aspect /map:aspects I don't like this and I don't see any reasonable use of the above system besides views. [c'mon, a logging aspect is much easier implemented by a different pipeline implementation, an admin-notifier is much better placed in a error-handler, where it belongs, and for flow-related actions, well, you know my opinion on those] What am I missing? Simple: AOP does not make you do more things, it factorizes common behaviours in a single place. If the places where these things must be placed are a lot, then it makes sense, else it doesn't. You have much more experience in seeing working systems, so you can judge better than me on this. ... *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. This is probably the point I'm missing. Instead of discussion the solution, can't we start over again from the problem? maybe there are easier solutions that you didn't think about. This is the last iteration of a looong discussion ;-) Summary: - CLI crawling link-views is slow - it's slow because it's multipass - make it monopass by instrumenting the pipeline with a gatherer - this brings 50% speed increase - but the instrumentation is not configurable: - no place where to tell where ti gather - no link filtering - add a filter to the links (done in CVS) - Vadim has the idea of using a tee instead So let's leave this where it is now till some real need comes up, and let's continue the thread from the last mail of Upayavira on this. Below the last comments. What do others think? Is it already possible to do this today with other components and skillful pipeline writing? what do you mean with this?
Re: [RT] Improving Sitemap and Flowscript
Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. Vadim
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. You are right - Nicola Ken is here mixing up Link View and Link Gathering - two different approaches. What he says though is relevant to the link gathering approach, i.e. that it could be implemented with an 'aspect' allowing the user to insert the gathering stage at any point in their pipeline, by attaching a gathering transformer to a label (defaulting to the last stage, just before the serializer). In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. Interesting point. That would also apply to the link translator, which, if confirm-extensions is used (which it is by default), is inserted before the serializer. So, to be able to pre-populate a persistent cache, you've got to (a) use link view (b) make sure you don't confirm extensions. Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. Having reread Nicola Ken's post, I think I understood it this time (rather than being confused by all the references to aspects as I was last time). He does propose an interesting and more generic way to achieve what Vadim has already suggested - using an XML Tee component to feed SAX events into two pipeline segments simultaneously. To do that hard coded would be hard, and require quite a bit of work within AbstractProcessingPipeline. Doing it in Nicola Ken's way strikes me as cleaner and more generic. So you'd be able to add 'aspects' that use generators/transformers/serializers in the following combinations: 1) G-T-S (pretty useless as it doesn't really interact with the pipeline as it is) 2) T-S (takes the current SAX events, using a Tee, and feeds them to a section of pipeline that serializes somewhere else - e.g. link view) 3) G-T (replaces or augments SAX events with an additional source) 4) T (transforms existing SAX events, e.g. link gatherer) So we get a generic way of implementing our two gathering methods, and probably some additional methods we hadn't thought of. In case 2), we'd probably want to have another component after the serializer which defines what to do with the content, e.g. an ObjectModelWriter that writes it to the ObjectModel, a FileWriter that writes it to a file (or more likely a SourceWriter). Does this make sense? Or is it barking? (barking is shorthand for 'barking mad', like wild dogs can be sometimes). Regards, Upayavira
Re: [RT] Improving Sitemap and Flowscript
Upayavira wrote: Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. You are right - Nicola Ken is here mixing up Link View and Link Gathering - two different approaches. What he says though is relevant to the link gathering approach, i.e. that it could be implemented with an 'aspect' allowing the user to insert the gathering stage at any point in their pipeline, by attaching a gathering transformer to a label (defaulting to the last stage, just before the serializer). Once we have links view working allright, we will kill link gathering alltogether -- anyway it was just a hack ;-) Vadim
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote, On 28/08/2003 14.00: Nicola Ken Barozzi wrote: snip/ *IMPORTANT* (and the reason why I started the RT): So in he CLI, instead of asking for the link view and then generate, I simply ask Cocoon to insert a transformer that gathers links in the same positions where the links view would. This would make it possible for the CLI to have the configurability of the view gatherer but the speed of the transfomer gatherer. Links view is not a transformer. It's a view, meaning that it can have actions, matchers, selectors, transformers, and should end with text serializer. So, you cannot simply add one transformer and think that you are done with links view. When I say Transformer here I mean Virtual Transformer, that can be all you say above, as I suggest in the RT. This also means that this virtual Transformer can also do the link exclusion and other things that are needed and that a simple transformer cannot do. In addition to this, adding a transformer would not work because this alters pipeline cache key which prevents such legitimate CLI usages as pre-populating persistent cache. I do not see the case in which this happens. Could you explain more please? Solution to the CLI problem was already found (attach links view as a tee to main pipeline, see Link View Goodness on approx 2003/07/01) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105708533500966w=2 and Upayavira is looking into ways of implementing it. I would help him out but right now I can't. I know, but doing it as I say is conceptually equivalent to attaching links tee to main pipeline, so it's an alternative way, but that has extra features. Conceptually generator inserted gatherer vt --- (links hashmap) serializer What propose generator inserted tee - view - parser --- (links hashmap) serializer Which is basically the same, only that I use a virtual transformer and you use a view. Make the view call the same virtual transformer, and the results are the same only that my proposal is more generic. Oh well, whatever, as long as it works... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote, On 28/08/2003 16.23: ... With a tee-view, pipeline would be: G[data] - T[content] - Tee - T[page] - T[html] - S - Browser \ - T[links] - Hashmap With a virtual transformer as far as I understand resulting pipeline will be: G[data] - T[content] - T[links] - LinkGatherer - T[page] - T[html] - S - Browser And the output sent to the browser will be garbage, right? Or, you are also proposing to use a tee (I haven't seen it in your proposal)? Thanks for explaining it this way, now I understand what you mean. Well, I did not talk of how to insert a T[links] section, so now I see why you say it is flawed. What I mean is that the LinkGatherer is a virtual transformer that does not modify its output WRT the input. How to do it is not part of my example, and using a tee is one way, using an xslt, then gathering, then retransforming again is another (kind of tee using namespaces). The problem arises when you insert the tee or the virtual transformer and have problems with caching, *or* have to keep that step even if you don't want it. Anyway, as I said, both are ok as long as it remains fast and gives us the features we need. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Improving Sitemap and Flowscript
On 26.Aug.2003 -- 06:43 PM, Stefano Mazzocchi wrote: On Monday, Aug 25, 2003, at 10:10 Europe/Rome, Christian Haul wrote: On 23.Aug.2003 -- 03:48 PM, Stefano Mazzocchi wrote: On Saturday, Aug 23, 2003, at 10:17 Europe/Rome, Christian Haul wrote: Stefano Mazzocchi wrote: On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote: I'm not suggesting we add AOP to Rhino, I'm suggesting we add the ability to avoid concern crosscutting in the cocoon flow. After reading Nicola Ken's message I believe this discussion is void but I still would like to explain my position as it appears it hasn't been clear enough. I've started using flow very shortly after the javascript incarnation arrived and I love flow. That is 1+ years using flow. I believed that adding AOP to Rhino (which happens to be the javascript engine in Cocoon) is beyond the scope of this project. Now you explained you don't want to do that but only add it to the invokation of flow functions. I believe that is a poor solution and does not provide enough usefulness to solve any of your examples but the authorization one. I can hardly disagree more. When you have function interception you have all you need to implement layers of invocation (and some people call those layers aspects, but I don't). This solves all the issues I previously listed (including, yes, AAA). Stefano, could you *please* explain what you are talking about? It appears that every time I try to rephrase your intentions you say, you are talking about a different thing. According to your mails, you don't want to * add aspects to Rhino * add interception only to flow invocation Where do you want to add your interception then?? However, as I said above, after reading Nicola Ken's mail I believe this dicussion is void because it appears AOP in javascript is as easy as saying aspect. In addition, I believe his proposal for aspects in the sitemap is balanced and very interesting. We should follow this idea further. I think we are talking about two different things here. Indeed, Nicola Ken's mail contains to different concepts. The first reads like a solution for aspects in javascript while the second is a completely new proposal. The reference to AOP fun with javascript is great. The proposal is very interesting. One thing is layering flow, another thing is layering pipeline definitions. If you allow me to remove actions from the picture just one second, you'll see how layering pipeline definitions might allow you to simplify (or ease reuse) of pipeline definition fragments, but you also understand how this is not going to help you on things that touch resource flow rather than resource production. This is no either-or situation. Why can't we have Nicola Ken's proposal and use the Aspects.js he references as well? Note: I stay away from the name aspect because it's a overhyped concept and too blurry to be used as a meaningful terminology because it means different things to anybody. Adding new names does not help either. IMO is the problem of aspects in flow solved by the existence of Aspects.js see http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript 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
Stefano Mazzocchi wrote, On 26/08/2003 18.43: ... I would like Nicola to update its RT on aspectizing the sitemap after the introduction of virtual components (which, IMO, solve most of the issues he outlined). Actually I already reference the concept: Hmmm, it also has to do with the named pipelines thread, or the pipeline==reusable_component one that Stefano had started. But I don't see a real direct benefit of virtual components in this RT yet as it's not the main point it seems to me. What is not covered, IMO, can be implemented by extending the view concept. Which is basically what the while RT is about IMHO. I see how things work now, how the view concept can be extended, and then how aspectized pipelines can be a bigger generalization of views. Below is the salient part of the RT with additions and comments in brackets Now I describe the current situation - pipelines are called per request one after the other till the sitemap exits - resources are sitemap snippets called by the pipelines - views are exit points that get called at a particular label (effectively a hard-wired AOP feature) by the sitemap Pipelines and resources are effectively the same thing not that there is the cocoon protocol. Calling a resource, inserting a virtual pipeline and using the cocoon: protocol are for most uses equivalent. What remains is the views part, that has introduced pipeline-stage metadata, as a label. It's an aspect that gets called when that particular condition is met IOW, I'm rephrasing, using different terminology, that a view is an orthogonal mechanism, that interacts with the normal sitemap using some metadata and an exit pipeline. The labels are effectively metadata, as they describe the pipeline. The exit pipelines, ie the views themselves, are what has to be done. (I won't use AOP terminology that I personally don't yet like) See, I don't like it too! ;-) So we can generalize it, and add configurability to the view mechanism to specify other conditions. Thus views effectively insert pipeline fragments at a certain condition. In fact they insert their contents after a label. So the label is the condition. *first proposal* I propose that we define other conditions. map:view name=content from-label=content map:serialize type=xml/ /map:view becomes: map:view name=content type=from-label test=content map:serialize type=xml/ /map:view This makes it possible to make a different position where to start from... What can also be made configurable is *when*, in which condition, it's triggered, but the logic has to be inverted. What I mean here is that views are triggered only by the user. Normal results are done *without* calling views. So if I want to say: insert a logger after each generator, I cannot do it easily, as I would have to call a logger-view for it to be called. And I would have only one possible insertion per pipeline, as only one view is called at a time. Now we say: when the view is triggered, start at a label After it could be: when the view is triggered, start at position Instead we need: when the position is met, check if it has to be triggered. Here is an example that uses this inverted AOPish system for views. Let me rephrase this: the following is a way of defining views in a more generic way. Here I don't say anymore: when the user asks for a view trigger the label (or more generic as in the first proposal) condition, but at every stage check if a condition is met, and if so execute the generalized view. *second proposal* Make it possible to tell Cocoon to add pipeline snippets (ie virtual pipelines) given certain rules. This makes it possible to have views be made with this more generic mechanism. The following adds two aspects: - an aspect gets called from every content position and gathers links. - the other one gets called from every content position. If the request has a cocoon-view=links, then the links are serialized. map:aspects map:aspect type=from-label test=content !-- Any required link munging -- map:transformer type=gather-links/ /map:aspect map:aspect type=from-label test=content map:action type=request-param map:param name=cocoon-view value=link map:serializer type=links/ /map:action /map:aspect /map:aspects This would make it very easy to add security-based checks, logging, or any other stuff. map:aspects map:aspect type=pipeline test=start map:action type=check-security/ /map:aspect map:aspect type=pipeline test=all map:transformer type=logger/ /map:aspect map:aspect type=error test=all map:action type=notify-admin/ /map:aspect /map:aspects With virtual pipelines (vp) we could as well do: map:aspects !-- if the from-label condition of the current pipeline component matches content, then insert right after it the virtual pipeline called gather-links and content-view. IOW add a link gatherer
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: 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. Out-of-the-blue-thought (and I had way too much wine last night): shouldn't this 'action-in-sitemap' thing be alleviated by an 'orthogonal-to-the-matchers' thing in the sitemap? So that you end up with a section in the sitemap describing the content-generating artefacts, and another one listing the authentication realms, maybe using the same matcher-like constructs describing which portions of the URI space should be protected? I'm having the slight feeling we are moving stuff into flowscript that can mess up good URI practices. /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
Re: [RT] Improving Sitemap and Flowscript
On Sunday, Aug 24, 2003, at 08:35 Europe/Rome, Steven Noels wrote: Stefano Mazzocchi wrote: 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. Out-of-the-blue-thought (and I had way too much wine last night): shouldn't this 'action-in-sitemap' thing be alleviated by an 'orthogonal-to-the-matchers' thing in the sitemap? So that you end up with a section in the sitemap describing the content-generating artefacts, and another one listing the authentication realms, maybe using the same matcher-like constructs describing which portions of the URI space should be protected? What you are describing is separating the content-producing artefacts from navigational behavior describing semantics. It's just another way of saying pipeline and flow, respectively. If you follow that paradigm, you will, pretty soon, understand that the semantics you need to fully describe flow will hardly be easy to write inside the sitemap, then you will end up rewriting what we already have. I'm having the slight feeling we are moving stuff into flowscript that can mess up good URI practices. I'm trying hard but I don't see it: rather the opposite. By providing layers of interception, we would be providing a transparent way to add AAA around any URL without worrying about making the AAA semantics explicit. We have, finally, an elegant way to kill the login page once and forever. Alas! One day I hope the anti-flow/pro-action people will simply stop sneaking doubts and come up with real arguments on why we shouldn't heavily bet on the flow. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: One day I hope the anti-flow/pro-action people will simply stop sneaking doubts and come up with real arguments on why we shouldn't heavily bet on the flow. I thought we were done with this balkanization thing, didn't we? I for one have just finished my first tiny flow-based application, and while I still find the edge layer where Java Javascript meet each other quite murky, I had good fun while hacking on it. It's not about just black white, Stefano. dreaming What I would like to see, even if some of it might be nonsense, is a seriously integrated scripting environment to code the behaviour of a webapp, and flowscript is a nice way to start exploring that concept. With serious, I mean there should be a way to work with persistency, security, and back-end business logic without this stupid Packages thing, and, because of the continuous bouncing back forward between Java and JS, not having to worry about the automagic typecasting that happens on the border between Java Javascript. Syntax-wise, I have about the same problem with JS as I have with Java, but that's because I find Python a tad more readible. There's people around here that would rather like to code flow in real Java, with dynamic recompilation and all that. There's room for diversity, and we should exploit that. Even Apples hooks in with the flow at some point. asideAnd Apples doesn't mean anything more to me than a personal adventure of a guy I like, on the same level of appreciation that Dywel has in my mind: nothing wrong with it, but where's the community?/aside We should work on serious JS-wrapping of services typically used in webapps, and extensive Avalonization of existing Cocoon code can help with that. There should be formalization of the border area between Java JS, or we will kill ourselves with recurring user questions about the lack of explicit semantics casting. Over time, I still hope that some Jython guru will pop up and make all this also possible using a language I've come to appreciate above JS, but that's entirely IMHO. /dreaming Of course, if we start from a discours of either you're with us, or you're against us, well, all this might take a long time to happen. As much as you repeatedly come back on this so-called split between pro and contra, I'm quite sure that you are currently misguiding yourself (and through such remarks, also this community) about this so-called polarization. For myself, I started hating overweight sitemaps a long time ago. I'm also pretty sure some of the old action-farts will be amongst the people who, eventually, will make sure flowscript reaches the same level of robustness, documentation and user support that the 'old stuff' already has. Oh, and I did read the rest of your mail, and you were right about AAA, interceptors and flow. I understand now. Thanks for your repeated efforts in educating the clueless. ;-D Cheers, /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
Re: [RT] Improving Sitemap and Flowscript
On Sunday, Aug 24, 2003, at 17:58 Europe/Rome, Steven Noels wrote: Stefano Mazzocchi wrote: One day I hope the anti-flow/pro-action people will simply stop sneaking doubts and come up with real arguments on why we shouldn't heavily bet on the flow. I thought we were done with this balkanization thing, didn't we? I for one have just finished my first tiny flow-based application, and while I still find the edge layer where Java Javascript meet each other quite murky, I had good fun while hacking on it. It's not about just black white, Stefano. The edges are rough. I cannot agree more. But this is *exactly* why I'm working hard in designing ways to polishing those edges without making anything else rougher. Anyway, criticizing keeps use flow-lovers honest and with feet on the ground, so keep it up. dreaming What I would like to see, even if some of it might be nonsense, is a seriously integrated scripting environment to code the behaviour of a webapp, and flowscript is a nice way to start exploring that concept. With serious, I mean there should be a way to work with persistency, security, and back-end business logic without this stupid Packages thing, and, because of the continuous bouncing back forward between Java and JS, not having to worry about the automagic typecasting that happens on the border between Java Javascript. I hate the Packages syntax as much as you do, believe me. But with real blocks, you will do var component = cocoon.getComponent(..); after having deployed your block live and you'll automagically get what you want (with implicit versioning and all that). It will be the *real* dream of avalon finally coming true, versioned hotdeploying of components cannot be given by no technology out there (only .NET has such a concept, but they don't have continuations!) Syntax-wise, I have about the same problem with JS as I have with Java, but that's because I find Python a tad more readible. There's people around here that would rather like to code flow in real Java, with dynamic recompilation and all that. There's room for diversity, and we should exploit that. Even Apples hooks in with the flow at some point. asideAnd Apples doesn't mean anything more to me than a personal adventure of a guy I like, on the same level of appreciation that Dywel has in my mind: nothing wrong with it, but where's the community?/aside What does the above have to do with adding interception to the flow? We should work on serious JS-wrapping of services typically used in webapps, and extensive Avalonization of existing Cocoon code can help with that. There should be formalization of the border area between Java JS, or we will kill ourselves with recurring user questions about the lack of explicit semantics casting. I totally agree, but again, this cannot work without blocks. [and it seems that nobody is catching up with my plan for implementation so I will have to get my hands dirty and implement the whole thing by myself, :-( Over time, I still hope that some Jython guru will pop up and make all this also possible using a language I've come to appreciate above JS, but that's entirely IMHO. once you have a way to add continuations in java, you can have your jython thing for free. /dreaming Of course, if we start from a discours of either you're with us, or you're against us, well, all this might take a long time to happen. As much as you repeatedly come back on this so-called split between pro and contra, I'm quite sure that you are currently misguiding yourself (and through such remarks, also this community) about this so-called polarization. For myself, I started hating overweight sitemaps a long time ago. I'm also pretty sure some of the old action-farts will be amongst the people who, eventually, will make sure flowscript reaches the same level of robustness, documentation and user support that the 'old stuff' already has. As I said, costructive criticism helps to keep people honest and I appreciate that. I just happen to be a little nervous when I hear comments that don't look costructive. And yes, I might be too sensible on the issue, given the past discussions. Oh, and I did read the rest of your mail, and you were right about AAA, interceptors and flow. I understand now. Thanks for your repeated efforts in educating the clueless. ;-D When we add interception to a flowscript with continuations, we'll be so much ahead of the current state of the art that people will need a time machine to understand what we are talking about. For this reason, I'm prepared to stand against years of people's inertia on radical paradigm changes, so I wouldn't say clueless, I would just say inertial. But I have seen too many faces illuminated by the continuations concepts. I can only wonder what continuations and interception, together, can do to them ;-) -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: [and it seems that nobody is catching up with my plan for implementation so I will have to get my hands dirty and implement the whole thing by myself, :-( Can't speak for others but I think the plan is still too complex for most of us to follow at this point. Oh, and I did read the rest of your mail, and you were right about AAA, interceptors and flow. I understand now. Thanks for your repeated efforts in educating the clueless. ;-D What is AAA? I tried looking throught the mailing list but was too lazy to scour through tons of AAA. None of the recent mail I can find gives an explanation of AAA. Is it something related to AOP? For this reason, I'm prepared to stand against years of people's inertia on radical paradigm changes, so I wouldn't say clueless, I would just say inertial. But I have seen too many faces illuminated by the continuations :) concepts. I can only wonder what continuations and interception, together, can do to them ;-) -- Boon Tek
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote: 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. Damn, great point. So, back one step: could adapt-environment help? or is environment not good enough for people to understand? What do others think? For the record, I'm +1 for it. 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
Finally :-) Stefano Mazzocchi wrote, On 16/08/2003 0.11: Virtual Pipeline Components --- ... It has been identified in several circumstances (but mostly dealing with blocks) that the need to use pipeline fragments is required. +1 Had been thinking the same thing for some weeks now for Forrest usage especially after the realization of the bug that makes resources misbehave (I'm so used to writing them the right way that I never found it). - o - Moving Sitemap components into cocoon.xconf --- -0 Don't have the need. Would like it more if each sitemap can have it's own cocoon.xconf besides it. Pluggable Request Factories --- Cocoon needs a simple way to deal with complex HTTP usages, such as binary uploading, XML-RPC, WebDAV or SOAP. +1 After a lot of discussion with Sylvain and input from many other people, I propose the introduction of a new sitemap element named map:adaptRequest that works by adapting the Request object into a more specific object that will parse the request and provide API-level access to the request. Stupid suggestion here, but what about map:adapt-request that is more xml-ish? ... 1) uploading granularity 2) mailet request handling (that can be made a special request factory and evolve independently from our environment) Finally ;-) - o - Interception in Flowscript I like the concept, and as I see you touting it here, I humbly ask you to take a look and give a brief comment about pipeline-level AOP I had suggested in my RT: [Aspect-based pipelines and link view] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105689706128203w=2 As for javascript AOP, read this: [AOP Fun with JavaScript] http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
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.
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: [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
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: [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.
Interception in Flowscript (was: [RT] Improving Sitemap and Flowscript)
From: Christian Haul [mailto:[EMAIL PROTECTED] Interception in Flowscript 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. I know, actions are not liked by everyone, but this is one of the best applications for them. So, please provide a more convincing use case for the introduction of AOP in Cocoon ;-) (Warning: the concept of AOP is rather new to me ...) When we polished the FOM some weeks ago we talked a lot about - pooled components I think AOP would be a great advantage because I only have to implement it once to get a Hibernate session and releasing it. Other use cases are - customized flows that have user exits without having to change the core flow - maybe error handling - logging - ... and of course authentication/authorization because I like to have it within the flow because IMHO applications are very easy to understand if the whole logic can be found at a single place. I think these are some good reasons and worth of thinking more about integrating AOP in flow. Cheers, Reinhard
Re: [RT] Improving Sitemap and Flowscript
Christian Haul wrote:
On 21.Aug.2003 -- 06:17 PM, Sylvain Wallez wrote:
Imagine that filteredFile above is actually defined as file in the
top-level sitemap because you want to *globally* change the file
generator inherited by subsitemaps.
Indeed, you are absolutely right.
Sorry for the noise.
Not noise : discussion ;-)
There's nothing worse than unwritten rants that lead to frustration !!
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
On Tuesday, Aug 19, 2003, at 23:51 Europe/Rome, Tony Collen wrote: Miles Elam wrote: Stefano Mazzocchi wrote: snip; 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. Except for the fact that cocoon.xconf is too verbose and this scares people away. While for the most part the contents of cocoon.xconf have no direct impact on the sitemap, the components are intimately tied. Not to mention being able to inherit components from super-sitemaps. I use this all the time and I'd hate to see this go away. No matter what we do, the ability to overload sitemap components in the sitemap will not go away. I'm just trying to reduce the verbosity of the main sitemap which has become way too big. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Wednesday, Aug 20, 2003, at 13:28 Europe/Rome, Carsten Ziegeler
wrote:
Sylvain Wallez wrote:
One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:
map:generate type=filteredFile src=afile.xml
map:parameter name=a parameter value=a value/
...
I assume that the src info and the parameters are passed to the
real
generator which in this case is the file generator. Is it
possible to pass
info to the other components as well, so can I pass a parameter to
the
xslt transformer?
I'm not sure if this is needed (or if it's FS); I have not
thought about it
but it immediately came up my mind :)
You really have to consider virtual components as typed resources,
this means we'll be able to pass parameters to these virtual
components
just a we do today for resources.
map:serializer type=abs-html
map:transform type=link-absolutizer
map:parametrer name=base-uri value={site-root}/
/map:transform
map:serialize type=html/
/map:serializer
and then :
map:serialize type=abs-html
map:parameter name=site-root value=http://my.host/root//
/map:serialize
Ah, ok ,so the given example:
map:generator name=filteredFile
map:generate type=file/
map:transform type=xslt src=namespaceFilter.xsl/
/map:generator
wouldn't work as the file generator would get not src, it has to:
map:generator name=filteredFile
map:generate type=file src={src}/
map:transform type=xslt src=namespaceFilter.xsl/
/map:generator
with
map:generate type=filteredFile
map:parameter name=src value=some.xml/
The only problem is for the src attribute. Should we simply pass it
as
a src parameter ?
+1, yes because then it would look like this:
map:generate type=filteredFile src=some.xml/
which is much more convenient.
I like this. +1
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Wednesday, Aug 20, 2003, at 11:14 Europe/Rome, Jay Freeman ((saurik)) wrote: Stefano: So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. Then, it does: map:match pattern=** map:mount check-reload=yes src=sitemap.xmap uri-prefix= / /map:match It makes more sense to me to use this already existing feature before tacking on a new one. I've already started using this solution on my websites and it seems to do the trick rather well (and also keep the default error handler in it so I don't need that in my sitemaps either). Sorry, but it looks hacky too me. Mostly because the components should be defined from above and not sideways (sorry, but that's how I visually perceive the thing). In short, I'd rather allow the sitemap to have components definitions somewhere else, either in cocoon.xconf or in the proposed components.xconf. I'd still like to see a better cocoon.xconf refactorization (so I could have a single file with just my datasources/ configuration), but I'm guessing real blocks would deal with that? Oh, that's for sure. When blocks are implemented the current cocoon.xconf will only contain configuration for the cocoon core, which are not that many (even today). Regardless, I still haven't gotten around to really reading through and absorbing the page on blocks that someone referred me to (so in reference to your other e-mail; this happened on the users list, though, not sure if you saw it). I'm not subscribed to the users@ list, no. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
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 ;-) 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. Correct analysis, but I'm not sure about the solution: I still think that components belong to the sitemap, and I tend to agree with Jay's suggestion to provide a base.xmap with component declarations and a sitemap.xmap with just pipelines. Yes, I think this is a better solution. Pluggable Request Factories --- Cocoon needs a simple way to deal with complex HTTP usages, such as binary uploading, XML-RPC, WebDAV or SOAP. After a lot of discussion with Sylvain and input from many other people, I propose the introduction of a new sitemap element named map:adaptRequest that works by adapting the Request object into a more specific object that will parse the request and provide API-level access to the request. Hmmm... need serious thinking here, a drawing board and some coffee. But here are a couple of eurocents: 1. I don't like the adaptRequest name, it's a bit inconsistent with other sitemap semantics: I'd go for adapt-request instead; Ok 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. Interception in Flowscript Adding interception mechanism to the flowscript requires three changes, two in the FOM, one (more important!) in the javascript syntax: Very interesting, even if, as Christian points out correctly, the AAA sample of yours might be done too using an action. Or even (hacky?) with nested flow calls: match pattern=myapp call function=checklogin/ /match match pattern=myapp/protected call function=main/ /match match pattern=myapp/login call function=login/ /match with checklogin being just a switchboard function redirecting to either myapp/protected or myapp/login. No, interception allows you to remove and compose aspects without requiring to rewrite any part of the code (only the section that identifies the intercepting patterns to apply). I agree that actions, in this sense, are more orthogonal. Will reply to Christian in more detail on this. But interception is way more than this, so I'd just love to have a bit of AOP in Cocoon flow. However, this brings me back to my pet peeve: adding such functionality on Rhino screams for a merge of our patches before even thinking of it. AOP in Javascript... how cool! Keep in mind that interception is not AOP, only one of the possible way to decompose a program into orthogonal layers that can be applied and removed. To me, it feels more like SoC at intra-function scripting level than anything else. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Thursday, Aug 21, 2003, at 17:45 Europe/Rome, Christian Haul wrote:
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
But, if you write
map:generate type=filteredFile src=something
then you can access it automatically as {src} rather than
writing
map:generate type=filteredFile
map:parameter name=src value=something/
We *will* regret this at some point. Don't handle @src different from
all other parameters. IOW we should pass everything using the
map:parameter syntax.
We haven't done it with resources. We shouldn't do it here.
Good point, but to me, src already is a special parameter for
generators and transformers, I see no problem in making it so for
virtual ones as well.
As for resources, they were not meant to be pipeline fragments anyway,
but entire pipelines, so a special src attribute doesn't make any
sense for an entire pipeline.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Friday, Aug 22, 2003, at 17:42 Europe/Rome, Christian Haul wrote: On 21.Aug.2003 -- 06:17 PM, Sylvain Wallez wrote: Imagine that filteredFile above is actually defined as file in the top-level sitemap because you want to *globally* change the file generator inherited by subsitemaps. Indeed, you are absolutely right. Sorry for the noise. No, please, no need for apologizing. I thank you for keeping a critic eye on new proposals. It makes them more solid and clarifies issues for others. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
On Tuesday, Aug 19, 2003, at 22:35 Europe/Rome, Miles Elam wrote:
Is only one interception possible?
No, of course not. You could have multiple interceptions, for example
main.js
function getBlah() {
return createBlah();
}
interceptor1.js
function get*() {
before();
continueExecution(arguments);
after();
}
interceptor2.js
function get*() {
before();
continueExecution(arguments);
after();
}
then, somewhere, it is defined that
[main.js -(wrapped by)- interceptor1.js] -(wrapped by) -
interceptor2.js
so, by calling getBlah() the resulting virtual function will be
function getBlah() {
before() // from interceptor2
before() // from interceptor1
_blah = createBlah()
after() // from interceptor1
after() // from interceptor2
return blah
}
Authentication is one use case for an interception. Authorization
could be another. I'm sure there are others. Would multiple calls to
cocoon.apply(...) be possible? Would they be order dependent?
Yes. Order of interception will need to be meaningful.
Also, am I correct in the assumption that the wildcard is intended to
match target functions?
yes
Doesn't that tie the two files too closely together?
it does create a contract on the function naming, yes. But I think this
is a good thing.
Or is this a change to the sitemap calling syntax. Does the sitemap
call getwhatever(...), a get* function intercepter catches it and then
eventually passes the call down to whatever(...)?
nononon, that would be totally against the spirit of aspect
orthogonality.
they key idea of transparent aspect layering is that you can remove the
aspect without touching the rest of the code.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:
map:generate type=filteredFile src=afile.xml
map:parameter name=a parameter value=a value/
...
I assume that the src info and the parameters are passed to the real
generator which in this case is the file generator. Is it
possible to pass
info to the other components as well, so can I pass a parameter to the
xslt transformer?
I'm not sure if this is needed (or if it's FS); I have not
thought about it
but it immediately came up my mind :)
You really have to consider virtual components as typed resources,
this means we'll be able to pass parameters to these virtual components
just a we do today for resources.
map:serializer type=abs-html
map:transform type=link-absolutizer
map:parametrer name=base-uri value={site-root}/
/map:transform
map:serialize type=html/
/map:serializer
and then :
map:serialize type=abs-html
map:parameter name=site-root value=http://my.host/root//
/map:serialize
Ah, ok ,so the given example:
map:generator name=filteredFile
map:generate type=file/
map:transform type=xslt src=namespaceFilter.xsl/
/map:generator
wouldn't work as the file generator would get not src, it has to:
map:generator name=filteredFile
map:generate type=file src={src}/
map:transform type=xslt src=namespaceFilter.xsl/
/map:generator
with
map:generate type=filteredFile
map:parameter name=src value=some.xml/
The only problem is for the src attribute. Should we simply pass it as
a src parameter ?
+1, yes because then it would look like this:
map:generate type=filteredFile src=some.xml/
How would you pass two or three src parameters?
which is much more convenient.
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt src=b.xsl/
/map:generator
5 src attributes.
Vadim
RE: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt src=b.xsl/
/map:generator
It works :)
You can then:
map:generate type=filteredFile
map:parameter name=source-a value=A/
map:parameter name=source-b value=B/
map:parameter name=source-c value=C/
/map:generate
with
map:generator name=filteredFile
map:aggregate
map:part src={source-a}/
map:part src={source-c}/
map:part src={source-b}/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt src=b.xsl/
/map:generator
You could also add two parameters for the stylesheets etc.
But, if you write
map:generate type=filteredFile src=something
then you can access it automatically as {src} rather than
writing
map:generate type=filteredFile
map:parameter name=src value=something/
Carsten
Re: [RT] Improving Sitemap and Flowscript
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt src=b.xsl/
/map:generator
It works :)
You can then:
map:generate type=filteredFile
map:parameter name=source-a value=A/
map:parameter name=source-b value=B/
map:parameter name=source-c value=C/
/map:generate
with
map:generator name=filteredFile
map:aggregate
map:part src={source-a}/
map:part src={source-c}/
map:part src={source-b}/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform type=xslt src=b.xsl/
/map:generator
You could also add two parameters for the stylesheets etc.
But, if you write
map:generate type=filteredFile src=something
then you can access it automatically as {src} rather than
writing
map:generate type=filteredFile
map:parameter name=src value=something/
With clarifications given -- no objections. I agree with this idea.
Vadim
Re: [RT] Improving Sitemap and Flowscript
Christian Haul wrote:
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
But, if you write
map:generate type=filteredFile src=something
then you can access it automatically as {src} rather than
writing
map:generate type=filteredFile
map:parameter name=src value=something/
We *will* regret this at some point. Don't handle @src different from
all other parameters. IOW we should pass everything using the
map:parameter syntax.
We haven't done it with resources. We shouldn't do it here.
But resources don't have a src attribute while generators and
transformer do.
Imagine that filteredFile above is actually defined as file in the
top-level sitemap because you want to *globally* change the file
generator inherited by subsitemaps.
Will this require to modify all of these sitemaps because the file
generator is now a virtual generator ? That's not viable. This is why
virtual components must be used using the *same* syntax as normal ones.
And src beeing part of this syntax, this is why we need a way to pass
it to the virtual component.
Now this changes nothing for resources, which never had that src
attributes and won't have it because of the introduction of virtual
components.
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: So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. Then, it does: map:match pattern=** map:mount check-reload=yes src=sitemap.xmap uri-prefix= / /map:match It makes more sense to me to use this already existing feature before tacking on a new one. I've already started using this solution on my websites and it seems to do the trick rather well (and also keep the default error handler in it so I don't need that in my sitemaps either). I'd still like to see a better cocoon.xconf refactorization (so I could have a single file with just my datasources/ configuration), but I'm guessing real blocks would deal with that? Regardless, I still haven't gotten around to really reading through and absorbing the page on blocks that someone referred me to (so in reference to your other e-mail; this happened on the users list, though, not sure if you saw it). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Stefano Mazzocchi [EMAIL PROTECTED] To: Apache Cocoon [EMAIL PROTECTED] Sent: Friday, August 15, 2003 5:11 PM Subject: [RT] Improving Sitemap and Flowscript ... 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. ... -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. :) +1 I think it could be called components.xconf since it is all about. I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? Note: merging map:components and cocoon.xconf will be worse. Newbies tend to keep away from cocooon.xconf because they simple does not understand it (I said that based in my own experience). Best Regards, Antonio Gallardo
Re: [RT] Improving Sitemap and Flowscript
note I resend again this post, since I dont got it in my mailbox. It seems like the 2 virus in the wild (Sobig.f and MSBlast) are causing major troubles in the Internet... Please stop using the major virus called Windows ;-D /note So, after making a request for this a few days ago, with some people's help (a suggestion to look into mounted sitemaps) there seems to be an already existing solution. Rather than adding extra functionality to support doing this in cocoon.xconf, wouldn't it make more sense to just ship an extra sitemap with the default distribution? It could exist in WEB-INF as like base.xmap or something and be referenced in cocoon.xconf as the main sitemap. :) +1 I think it could be called components.xconf since it is all about. I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? Note: merging map:components and cocoon.xconf will be worse. Newbies tend to keep away from cocooon.xconf because they simple does not understand it (I said that based in my own experience). Best Regards, Antonio Gallardo
Re: [RT] Improving Sitemap and Flowscript
Antonio: The complaint I would have about a complete seperation of sitemaps (rather than my original sitemap override proposal, or my revised just use mounted subsitemaps) is that then, if you have a particular component that you want in your app, or a particular configuration of an existing one, you're back modifying the base sitemap. I would want components to be capable of going in either, and subsitemaps do that without any changes to the overall code :). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 5:57 AM Subject: Re: [RT] Improving Sitemap and Flowscript ... I think it could not be a big change if we separate the current sitemap.xmap in: WEB-INF/components.xconf- map:components part of current sitemap.xmap sitemap.xmap- just map:pipelines To dont make the change to traumatic to the overall code, initially we can specialize a class of the current sitemap processor that just will merge this to files in in once and give the control back to the current sitemap processor. What do you think? ... Best Regards, Antonio Gallardo
[RT] Improving Sitemap and Flowscript
Virtual Pipeline Components --- Currently, people abuse the map:resource part of the sitemap to create pipeline fragments to call. This was introduced by the TreeProcessor implementation of the sitemap but map:resources were *not* designed to be pipeline fragments but entire pipelines. It has been identified in several circumstances (but mostly dealing with blocks) that the need to use pipeline fragments is required. I propose the creation of virtual pipeline components by aggregating two or more components into a virtual one. An example is map:components map:generators map:generator name=filteredFile map:generator type=file/ map:transformer type=xslt src=namespaceFilter.xsl/ /map:generator map:transformers map:transformer type=skin map:transformer type=xslt src=fancy-doc2html.xslt/ /map:transformer /map:transformers map:serializers map:serializer type=html map:transformer type=linkTranslator/ map:serializer type=html/ /map:serializer /map:serializers /map:components As you can see from the example, with virtual components, we can: 1) reuse pipeline fragments as they were one component. 2) overload existing components with additional functionality 3) specify the src of a general purpose component (for example, xslt) and reuse that particular instance as a component. [useful for precompilation of general purpose transformations or for reusing pipeline services implemented by blocks] The virtual compoments can include any other sitemap component but: 1) for generators, all but serializers 2) for transformers, all but generators and serializers 3) for serializers, all but generators and, obviously, the order is important. - o - 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. - o - Pluggable Request Factories --- Cocoon needs a simple way to deal with complex HTTP usages, such as binary uploading, XML-RPC, WebDAV or SOAP. After a lot of discussion with Sylvain and input from many other people, I propose the introduction of a new sitemap element named map:adaptRequest that works by adapting the Request object into a more specific object that will parse the request and provide API-level access to the request. For example, in case of file upload, map:match src=/whatever/upload map:adaptRequest type=upload map:call function=upload()/ /map:adaptRequest /map:match the upload() function will be passed a UploadRequest object which extends Request and will be 'upcasted' by the script that uses it. The same thing can happen for WebDAV or SOAP, where specific protocol-specific Request handlers will be passed and will be used by the script. Note that upcasting requires a contract between the request object user and the sitemap writer. We believe this to be reasonable. NOTE: the above removes the need for the pipeline extractor *and* removes the need for pipe-aware selectors. In fact, pipe-aware selection is not required if the proper information is extracted from the pipeline and made available to the environment. Instead of using extraction, the request is adapted by a specific request factory. The factories are made part of the sitemap components map:components ... map:request-factories map:request-factory name=upload src=... save-on-disktrue/save-on-disk map-upload100/max-upload ... /map:request-factory /map:request-factories ... /map:components this also solves the issue with 1) uploading granularity 2) mailet request handling (that can be made a special request factory and evolve independently from our environment) - o - 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,
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote:
I propose the creation of virtual pipeline components by aggregating
two or more components into a virtual one.
Love it. Love it. Love it!
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.
Except for the fact that cocoon.xconf is too verbose and this scares
people away. While for the most part the contents of cocoon.xconf have
no direct impact on the sitemap, the components are intimately tied.
What is the problem with specifying a new file like components.xconf
or specifying it in the sitemap? For example
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components src=components.xconf/
...
/map:sitemap
Doesn't RelaxNG allow differing element content depending on attribute
value? (I think so.) This would allow validation for this example and
putting component definitions in the map:components element as it is today.
In other words, if the components are in the sitemap.xmap file, nothing
changes; But in the cases where having the components in a separate
file make sense, it is clear where these definitions are located. (An
often overlooked issue.)
Imagine this: A new user fires up Cocoon and wonders where the sitemap
components are defined or, more likely, wonders what sitemap components
are available. Off goes a question to the mailing list. (People don't
read docs, remember? ;-) An option here would be to add a comment here
to the effect of Sitemap component definitions are in
WEB-INF/cocoon.xconf. So the newbie goes to cocoon.xconf and is
confronted with not just the sitemap component definitions, but all of
the components in use by the system and their configurations, roles,
etc. The complexity and intimidation is still there, just shifted off
to another file.
- or -
A new user fires up Cocoon and wonders where the components are defined
or, more likely, wonders what components are available. At the top of
the sitemap in the map:components element is a reference to the file
that contains the definitions (and only the definitions).
Am I completely off-base here?
Pluggable Request Factories
---
Cocoon needs a simple way to deal with complex HTTP usages, such as
binary uploading, XML-RPC, WebDAV or SOAP.
Indeed.
After a lot of discussion with Sylvain and input from many other
people, I propose the introduction of a new sitemap element named
map:adaptRequest that works by adapting the Request object into a
more specific object that will parse the request and provide API-level
access to the request.
Very nice!
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.
Interesting...
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*() {
...
}
snip-great-authorization-example /
Is only one interception possible? Authentication is one use case for
an interception. Authorization could be another. I'm sure there are
others. Would multiple calls to cocoon.apply(...) be possible? Would
they be order dependent?
Also, am I correct in the assumption that the wildcard is intended to
match target functions? Doesn't that tie the two files too closely
together? Or is this a change to the sitemap calling syntax. Does the
sitemap call getwhatever(...), a get* function intercepter catches it
and then eventually passes the call down to whatever(...)?
- Miles Elam
Re: [RT] Improving Sitemap and Flowscript
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. I know, actions are not liked by everyone, but this is one
of the best applications for them.
So, please provide a more convincing use case for the introduction of
AOP in Cocoon ;-)
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
