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...
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]> asks: > 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? > 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. You've pretty well gotta have some comfort with OO terms if you're touching Cocoon... 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.
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
Stefano Mazzocchi wrote:
On Saturday, Aug 23, 2003, at 15:41 Europe/Rome, Gianugo Rabellino wrote:
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.
ah, yeah, rings a bell... I remember that I thought about
fragmented resources and it was that that triggered my FS alarm. I
always knew that views were virtual serializers, but the specific
semantics was introduced to make it easier to understand (views are
heard enough to understand already).
But anyway, no excuse, I was probably wrong at that time not to
consider this further. Or, maybe not: we needed more time to see if it
really made sense to add that complexity.
I will be more stubborn next time. ;-)
Please do :-)
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".
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote, On 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 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 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. 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"? All the above stuff. For doing it at the beginning or at the end of a request it's possible to have an entry-point pieline that has pre and post processing, but to add stuff *inside* other pipelines? I think it cannot be done today. Sorry, but I'm lost. I
Re: [RT] Improving Sitemap and Flowscript
Stefano, *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. Well. The 'problem' is this: By default, the CLI generates a page twice, once for the page and once for its links. This is inefficient. To work around this, I added the ability to automagically insert a LinkGatherer before the serializer. But with this you loose the configurability of the link view method. Some of this can be worked around by improving the CocoonBean, e.g. adding include/exclude capabilities, but some can't - particularly the ability to extract links from somewhere earlier in the pipeline when generating non-HTML content. So the desire is for a way to gather links from a page that: 1) Is efficient (i.e. doesn't require complete regeneration of the page just for its links) 2) Can handle non-HTML content where links must be gathered earlier in the pipeline (and other flexibilities achievable using link view) 3) Minimal (or preferably no) change to the sitemap language We have link view and link gathering at present. Both work, but neither of them are in themselves ideal. A link view that is efficient could replace both, as a link view can be by default configured to happen just before the serializer, which is what is currently happening with the Link Gatherer. Vadim suggested using a tee pipe to simultaneously feed SAX events into both the remainder of the normal pipeline and into a view pipeline, and I'm continuing to reflect and explore how this could be done. It certainly wouldn't be easy, especially if you want to retain cachability. But that's getting into the area of solution, so I'll stop there. Regards, Upayavira
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 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 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 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.< becomes: 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. 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 checks, logging, or any other stuff. 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? > With virtual pipelines (vp) we could as well do:
Re: [RT] Improving Sitemap and Flowscript
On Wednesday, Aug 27, 2003, at 11:52 Europe/Rome, Christian Haul wrote: 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?? I'm sorry, I'll try to be as explicit as possible: I want to add interception capabilities to the flow as currently implemented with continuation-enabled scripting. I don't care how this ends up being implemented (means: I don't care if this comes from a patch in Rhino or a wrapper around it). I also stated that I wouldn't be against interception in other areas of cocoon (ie sitemap) but this is an entirely different issue and not something that itches me. 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 Maybe I'm blind, but I don't see this. The interception mechanism that I proposed allows to compose layers of scripting without touching code. This Aspects.js proposes an explicit machinery that you use to compose your own script. My goal is to allow composability of scripting layers without needing to change code inside them. I don't see how can this be achieved with Aspects.js -- Stefano.
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
Vadim Gritsenko wrote, On 28/08/2003 15.22: ... Once we have links view working allright, we will kill link gathering alltogether -- anyway it was just a hack ;-) The real hack is having a CLI that uses a Cocoon object that uses a a sitemap... these should encapsulate thenselves, but fail to do it, since the CLI will not work if the sitemap lacks a certain view. This is a break of SOC and a hack. Making link gathering part of the contract instead de-hacks it and brings all in order. So as I see it, it's the other way round, but again, I'm just a fool as usual. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Improving Sitemap and Flowscript
Nicola Ken Barozzi wrote: Vadim Gritsenko wrote, On 28/08/2003 14.00: Nicola Ken Barozzi wrote: *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? Somebody had an idea of running CLI to pre-populate Cocoon cache so when servlet is running all the pages are already cached. But there is a problem preventing doing so, currently observed with CLI working with LinkGatherer (later: LG). When running from the CLI, pipeline assembled, and key generated, is G-T-...-LG-S, and resulting page is stored in the cache. When running as a servlet, key is G-T-...-S (no GT anymore), and cache lookup returns null. 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-dev&m=105708533500966&w=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... May be I'm missing something. How the following setup will work with your proposal: 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)? Vadim
Re: [RT] Improving Sitemap and Flowscript
Vadim Gritsenko wrote, On 28/08/2003 14.00: Nicola Ken Barozzi wrote: *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-dev&m=105708533500966&w=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
Upayavira wrote: Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: *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: Nicola Ken Barozzi wrote: *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
Nicola Ken Barozzi wrote: *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
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< - are called per request one after the other till the sitemap exits - are sitemap snippets called by the pipelines - 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 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.< becomes: 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. This would make it very easy to add security-based checks, logging, or any other stuff. > With virtual pipelines (vp) we could as well do: Note that the virtual pipeline can also contain the call to the flowscript, so I can effectively ask Cocoon to pass any condition to the flow, and use it for more effective management. *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. < What do others think? Is it already possible to do this today with other components and skillful pipeline writing? For doing it at the beginning or at the end of a request it's possible to have an entry-point pieline that has pre and post processing, but to add stuff *inside* other pipelines? I think it cannot be done today. -- Nicola Ken Bar
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
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). 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. 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. In a sense, resource views and virtual components already provide pipeline layering. 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). What is not covered, IMO, can be implemented by extending the view concept. 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. -- Stefano.
Re: [RT] Improving Sitemap and Flowscript
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. 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. 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
AOP (was Re: [RT] Improving Sitemap and Flowscript)
On 25.Aug.2003 -- 12:04 AM, Nicola Ken Barozzi wrote: > Stefano Mazzocchi wrote, On 16/08/2003 0.11: > > 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-dev&m=105689706128203&w=2 Very interesting stuff, indeed. > As for javascript AOP, read this: > > [AOP Fun with JavaScript] > http://freeroller.net/comments/deep?anchor=aop_fun_with_javascript Great link (although I had to go through Google's cache as it appears to be dead) 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
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-dev&m=105689706128203&w=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
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
Boon Hian Tek 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? Authentication, Authorization and Accounting, the three phase that make up an application security. Authentication is "who you are", authorization is "what you can do", accounting is "what you have done". 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
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
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. 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. And 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? 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. 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: 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. 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. And 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? 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. 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 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: 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 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: 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 > > > > > > > ... > > > > 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 15:41 Europe/Rome, Gianugo Rabellino wrote: 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. ah, yeah, rings a bell... I remember that I thought about fragmented resources and it was that that triggered my FS alarm. I always knew that views were virtual serializers, but the specific semantics was introduced to make it easier to understand (views are heard enough to understand already). But anyway, no excuse, I was probably wrong at that time not to consider this further. Or, maybe not: we needed more time to see if it really made sense to add that complexity. I will be more stubborn next time. ;-) Please do :-) 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". 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? -- 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
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 ... 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 10:17 Europe/Rome, Christian Haul wrote: 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 ;-) eheh, that means that you wrote that at 22:41 CET, not that you were in Rome writing it. 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. Yeah, sorry, a little over the line. 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. Yes, actions can be used well and flow abused. But the chance of abusing actions and using the flow well are much bigger, IMO. 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. Exactly. Error handling *is* flow. Actions exhibit such a bad mindset that flow is the "right thing" and "errors happen rarely" that even the syntax reflects this (jumping *outside* the action tag, which is hacky as hell!) 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. sorry, mate, but this argument is the weakest I ever heard. In fact, any new information technology could be seen as touching a concept for which we already have a solution. The problem is not finding *one* possible solution (a turing machine *is* a solution for every computational problem), but a better one. Best is, obviously, a subjective concept and there is no objective metric so I won't even try to define one. I'm presenting a solution that appears, to my personal taste, more elegant than the existing one. You might well disagree and I will highly respect you for this, but don't come up with the duplication argument because that's BS. This solution is not as elegant as AOP but it's here and it's usable. So use it, for &deity;'s sake. I will never stop you from using it, but I will not lock myself into such an inelegant solution. 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 ;-) When I was at Sylvain's, Marcus asked us how we envisioned the ability to move global variables between different flows (i.e. flows that are not nested, but located side by side). This is an obvious requirement for sigle sign-on. Several options were suggested by the three of us, but the one that appeared more elegant from a cocoon point of view was the use of an interception mechanism. I'm not suggesting we add AOP to Rhino, I'm suggesting we add the ability to avoid concern crosscutting in the cocoon flow. I can hardly think of anything more focused on cocoon than this. I'll think about more juicy use cases tonight. Great! 1) bridging This was suggested by something that happened to Ricardo. A company designed a web application that included some 300 servlets, all directly connecting via JDBC to a database. They implemented their own connection pooling, which was crosscutted all over the place. They had a threading problem and they were both lossing data and have zombie connections in the pool, causing memory and performance issues. Ricardo, faced with the task of solving the issue, used interception, wrapped everything with his own connection pooling controller and released those connections that were not released by the pool. 80 lines of java code and a few days job. Hacky, granted, but wonderful effectivity/energy ratio. In the future, many of us will be asked to fix flows that don't work as expected. Interception provides us another tool. 2) external resource control this is an instance of the above. optimization of external resources
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
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 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
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-dev&m=106153567628087&w=2 Reinhard
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
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). Sincerely, Jay Freeman (saurik) [EMAIL PROTECTED] - Original Message - From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 22, 2003 12:39 PM Subject: Re: [RT] Improving Sitemap and Flowscript ... > > 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. ... > -- > Stefano.
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
---
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
---
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
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
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 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
then you can access it automatically as {src} rather than
writing
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 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: 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 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: 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 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 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: ... 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. and then : http://my.host/root/"/> Ah, ok ,so the given example: wouldn't work as the file generator would get not src, it has to: with 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: which is much more convenient. I like this. +1 -- Stefano.
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
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 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. 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
Christian Haul wrote:
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
But, if you write
then you can access it automatically as {src} rather than
writing
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
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
It works :)
You can then:
with
You could also add two parameters for the stylesheets etc.
But, if you write
then you can access it automatically as {src} rather than
writing
With clarifications given -- no objections. I agree with this idea.
Vadim
Re: [RT] Improving Sitemap and Flowscript
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
> But, if you write
>
>
> then you can access it automatically as {src} rather than
> writing
>
>
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.
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
Vadim Gritsenko wrote:
> It could be convinient if it would work. But it does not.
>
>
>
>
>
>
>
>
>
>
>
It works :)
You can then:
with
>
>
>
>
>
>
>
>
>
You could also add two parameters for the stylesheets etc.
But, if you write
then you can access it automatically as {src} rather than
writing
Carsten
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: ... 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. and then : http://my.host/root/"/> Ah, ok ,so the given example: wouldn't work as the file generator would get not src, it has to: with 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: 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. 5 src attributes. Vadim
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-> part of current > sitemap.xmap sitemap.xmap-> just > > 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
Re: [RT] Improving Sitemap and Flowscript
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... ;-) 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. 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; 2. Are you sure that adapting the request is enough? 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. 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: with "checklogin" being just a switchboard function redirecting to either "myapp/protected" or "myapp/login". 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! 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
Sylvain Wallez wrote: > >One thing missing is passing information from the pipeline to the > >components. > >For example if you write this pipeline: > > > > > > > >... > > > >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. > > > > > > > > > and then : > > http://my.host/root/"/> > > Ah, ok ,so the given example: wouldn't work as the file generator would get not src, it has to: with > > 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: which is much more convenient. Carsten
Re: [RT] Improving Sitemap and Flowscript
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 > 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-> part of current sitemap.xmap sitemap.xmap-> just 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 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
> 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-> part of current sitemap.xmap sitemap.xmap-> just 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 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
Tony Collen wrote:
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.
Hey, there's absolutely *no reason* to remove component inheritance !
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
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Virtual Pipeline Components
---
+5, the only thing I'm not sure about is the syntax in the sitemap, you
propose:
because in order to work correctly you have to define the file generator
as usual:
The src of the above statement points to a class where the src attribute of
the transformer above points to a file, so wouldn't it be better to write:
and "reuse" the "pipeline syntax". I'm not sure which one is better, but I
really like that you don't propose using a different components section
in the sitemap for Virtual Pipeline Components, map:virtual-generator etc.
+1 (I guess Stefano actually made a typo here).
And also because a virtual component can contain other sitemap
constructs such as matchers, etc.
One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:
...
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.
and then :
http://my.host/root/"/>
The only problem is for the "src" attribute. Should we simply pass it as
a "src" parameter ?
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: 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 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
Stefano Mazzocchi wrote: > > Virtual Pipeline Components > --- > +5, the only thing I'm not sure about is the syntax in the sitemap, you propose: > > > > > because in order to work correctly you have to define the file generator as usual: The src of the above statement points to a class where the src attribute of the transformer above points to a file, so wouldn't it be better to write: > > > > > and "reuse" the "pipeline syntax". I'm not sure which one is better, but I really like that you don't propose using a different components section in the sitemap for Virtual Pipeline Components, map:virtual-generator etc. One thing missing is passing information from the pipeline to the components. For example if you write this pipeline: ... 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 :) Carsten
Re: [RT] Improving Sitemap and Flowscript
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. - Tony
Re: [RT] Improving Sitemap and Flowscript
Stefano Mazzocchi wrote:
Virtual Pipeline Components
---
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
---
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
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
http://apache.org/cocoon/sitemap/1.0";>
...
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*() {
...
}
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
