You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/08/16 00:11:59 UTC
[RT] Improving Sitemap and Flowscript
Virtual Pipeline Components
---------------------------
Currently, people abuse the map:resource part of the sitemap to create
pipeline fragments to call. This was introduced by the TreeProcessor
implementation of the sitemap but map:resources were *not* designed to
be pipeline fragments but entire pipelines.
It has been identified in several circumstances (but mostly dealing
with blocks) that the need to use pipeline fragments is required.
I propose the creation of "virtual pipeline components" by aggregating
two or more components into a virtual one. An example is
<map:components>
<map:generators>
<map:generator name="filteredFile">
<map:generator type="file"/>
<map:transformer type="xslt" src="namespaceFilter.xsl"/>
</map:generator>
<map:transformers>
<map:transformer type="skin">
<map:transformer type="xslt" src="fancy-doc2html.xslt"/>
</map:transformer>
</map:transformers>
<map:serializers>
<map:serializer type="html">
<map:transformer type="linkTranslator"/>
<map:serializer type="html"/>
</map:serializer>
</map:serializers>
</map:components>
As you can see from the example, with virtual components, we can:
1) reuse pipeline fragments as they were one component.
2) overload existing components with additional functionality
3) specify the src of a general purpose component (for example, xslt)
and reuse that particular instance as a component. [useful for
precompilation of general purpose transformations or for reusing
pipeline services implemented by blocks]
The virtual compoments can include any other sitemap component but:
1) for generators, all but serializers
2) for transformers, all but generators and serializers
3) for serializers, all but generators
and, obviously, the order is important.
- o -
Moving Sitemap components into cocoon.xconf
-------------------------------------------
the default sitemap is too verbose and this scares people away. I would
like to move the default sitemap component definitions into the
cocoon.xconf.
Note that with blocks, the definitions of those components will be in
the block.xconf as well and this will be aggregated by the block
manager.
- o -
Pluggable Request Factories
---------------------------
Cocoon needs a simple way to deal with complex HTTP usages, such as
binary uploading, XML-RPC, WebDAV or SOAP.
After a lot of discussion with Sylvain and input from many other
people, I propose the introduction of a new sitemap element named
"map:adaptRequest" that works by adapting the Request object into a
more specific object that will parse the request and provide API-level
access to the request.
For example, in case of file upload,
<map:match src="/whatever/upload">
<map:adaptRequest type="upload">
<map:call function="upload()"/>
</map:adaptRequest>
</map:match>
the upload() function will be passed a UploadRequest object which
extends Request and will be 'upcasted' by the script that uses it.
The same thing can happen for WebDAV or SOAP, where specific
protocol-specific Request handlers will be passed and will be used by
the script.
Note that upcasting requires a contract between the request object user
and the sitemap writer. We believe this to be reasonable.
NOTE: the above removes the need for the pipeline extractor *and*
removes the need for pipe-aware selectors. In fact, pipe-aware
selection is not required if the proper information is extracted from
the pipeline and made available to the environment. Instead of using
extraction, the request is adapted by a specific request factory.
The factories are made part of the sitemap components
<map:components>
...
<map:request-factories>
<map:request-factory name="upload" src="...">
<save-on-disk>true</save-on-disk>
<map-upload>1000000</max-upload>
...
</map:request-factory>
</map:request-factories>
...
</map:components>
this also solves the issue with
1) uploading granularity
2) mailet request handling (that can be made a special request factory
and evolve independently from our environment)
- o -
Interception in Flowscript
----------------------------
While writing flowscripts, you realize how many things can be applied
to many of the various flowscript functions that are called by the
sitemap. In Linotype, I ended up using the ability that javascript
gives you of using functions as native objects and then invoquing them
by passing a modified argument vector.
It came to me that what I did with linotype was a really-poor-man
interception mechanism. Interception is the ability to "intercept" a
method call and execute some code before or after the execution of the
intercepted method.
Interception is the simplest form of the aspect orientation.
Adding interception mechanism to the flowscript requires three changes,
two in the FOM, one (more important!) in the javascript syntax:
1) the addition of a function call to the "cocoon" object, 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.
With interception, it can be implemented as such
login.js
var user;
var password;
var role;
function *() {
var userManager = cocoon.getComponent("UserManager");
while (true) {
sendPageAndWait("login", { user : user, password : password });
user = cocoon.request.user;
password = cocoon.request.password;
if (userManager.isValid(user, password)) {
role = userManager.getRole(user);
continueExecution(arguments);
break;
}
}
then, in your flowscript, you simply have to call the "apply" function
to apply the aspects to your flowscript
yourstuff.js
cocoon.apply("login.js");
function whatever(blah) {
doSomething(blah);
}
- o -
Ok, that's it for now.
Ciao
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
> So, after making a request for this a few days ago, with some people's
> help (a suggestion to look into mounted sitemaps) there seems to be an
> already existing solution. Rather than adding extra functionality to
> support doing this in cocoon.xconf, wouldn't it make more sense to just
> ship an extra sitemap with the default distribution? It could exist in
> WEB-INF as like base.xmap or something and be referenced in cocoon.xconf
> as the main sitemap.
:) +1 I think it could be called "components.xconf" since it is all about.
I think it could not be a big change if we separate the current
sitemap.xmap in:
WEB-INF/components.xconf -> <map:components> part of current sitemap.xmap
sitemap.xmap -> just <map:pipelines>
To dont make the change to "traumatic" to the overall code, initially we
can specialize a class of the current sitemap processor that just will
merge this to files in in once and give the control back to the "current
sitemap processor".
What do you think?
Note: merging <map:components> and cocoon.xconf will be worse. Newbies
tend to keep away from cocooon.xconf because they simple does not
understand it (I said that based in my own experience).
Best Regards,
Antonio Gallardo
Re: [RT] Improving Sitemap and Flowscript
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
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)
saurik@saurik.com
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <de...@cocoon.apache.org>
Sent: Saturday, August 23, 2003 8:51 AM
Subject: Re: [RT] Improving Sitemap and Flowscript
...
> Ok, here is what I think it would be wise to do:
>
> 1) leave cocoon.xconf as is
>
> 2) allow the sitemap to get components configurations from an external
> file or from an inside definition (as today).
>
> 3) write our main sitemap pointing to its components to an external
> file.
>
> The proposed sitemap syntax is something like
>
> <map:sitemap>
>
> <map:components src="blah.xconf"/>
>
> <map:pipelines>
> ...
> </map:pipelines>
> </map:sitemap>
>
> In case, both src="" and internal components are defined, these
> overload the ones included in the file.
>
> How does this sound?
>
> > --
> Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
On Saturday, Aug 23, 2003, at 08:45 Europe/Rome, Jay Freeman ((saurik))
wrote:
> Stefano:
>
> Could you describe what you mean by "above" and "sideways"? :) I'm not
> sure
> what you are seeing, hehe. To me the "super-sitemap" (which is kind of
> what
> this would be, as the main sitemap would be a subsitemap of it) is
> "above"
> the sitemap, and cocoon.xconf is relatively unrelated and is therefor
> "sideways" from the sitemap.
>
> Also, to me at least there seems to be more of a "hackish" feeling in
> having
> to different ways to setup components, one using xconf semantics, and
> one
> using sitemap semantics. I'd rather have the base.xmap one where you
> can
> have an extra file of just component definitions from a sitemap that
> are
> overridden by the sitemap itself rather than putting that same thing
> in the
> xconf... at least the layout of the file would be the same (but that
> still
> seems hackish in the sense that this extra feature was added to support
> what's pretty much a limited super-sitemap).
Ok, here is what I think it would be wise to do:
1) leave cocoon.xconf as is
2) allow the sitemap to get components configurations from an external
file or from an inside definition (as today).
3) write our main sitemap pointing to its components to an external
file.
The proposed sitemap syntax is something like
<map:sitemap>
<map:components src="blah.xconf"/>
<map:pipelines>
...
</map:pipelines>
</map:sitemap>
In case, both src="" and internal components are defined, these
overload the ones included in the file.
How does this sound?
> --
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
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)
saurik@saurik.com
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <de...@cocoon.apache.org>
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
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 20, 2003, at 11:14 Europe/Rome, Jay Freeman
((saurik)) wrote:
> Stefano:
>
> So, after making a request for this a few days ago, with some people's
> help
> (a suggestion to look into mounted sitemaps) there seems to be an
> already
> existing solution. Rather than adding extra functionality to support
> doing
> this in cocoon.xconf, wouldn't it make more sense to just ship an extra
> sitemap with the default distribution? It could exist in WEB-INF as
> like
> base.xmap or something and be referenced in cocoon.xconf as the main
> sitemap. Then, it does:
>
> <map:match pattern="**">
> <map:mount check-reload="yes" src="sitemap.xmap" uri-prefix="" />
> </map:match>
>
> It makes more sense to me to use this already existing feature before
> tacking on a new one. I've already started using this solution on my
> websites and it seems to do the trick rather well (and also keep the
> default
> error handler in it so I don't need that in my sitemaps either).
Sorry, but it looks hacky too me. Mostly because the components should
be defined from "above" and not "sideways" (sorry, but that's how I
visually perceive the thing).
In short, I'd rather allow the sitemap to have components definitions
somewhere else, either in cocoon.xconf or in the proposed
components.xconf.
> I'd still like to see a better cocoon.xconf refactorization (so I
> could have
> a single file with just my <datasources/> configuration), but I'm
> guessing
> "real blocks" would deal with that?
Oh, that's for sure. When blocks are implemented the current
cocoon.xconf will only contain configuration for the cocoon core, which
are not that many (even today).
> Regardless, I still haven't gotten
> around to really reading through and absorbing the page on blocks that
> someone referred me to (so in reference to your other e-mail; this
> happened
> on the users list, though, not sure if you saw it).
I'm not subscribed to the users@ list, no.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by "Jay Freeman (saurik)" <sa...@saurik.com>.
Stefano:
So, after making a request for this a few days ago, with some people's help
(a suggestion to look into mounted sitemaps) there seems to be an already
existing solution. Rather than adding extra functionality to support doing
this in cocoon.xconf, wouldn't it make more sense to just ship an extra
sitemap with the default distribution? It could exist in WEB-INF as like
base.xmap or something and be referenced in cocoon.xconf as the main
sitemap. Then, it does:
<map:match pattern="**">
<map:mount check-reload="yes" src="sitemap.xmap" uri-prefix="" />
</map:match>
It makes more sense to me to use this already existing feature before
tacking on a new one. I've already started using this solution on my
websites and it seems to do the trick rather well (and also keep the default
error handler in it so I don't need that in my sitemaps either).
I'd still like to see a better cocoon.xconf refactorization (so I could have
a single file with just my <datasources/> configuration), but I'm guessing
"real blocks" would deal with that? Regardless, I still haven't gotten
around to really reading through and absorbing the page on blocks that
someone referred me to (so in reference to your other e-mail; this happened
on the users list, though, not sure if you saw it).
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: "Apache Cocoon" <de...@cocoon.apache.org>
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.
AOP (was Re: [RT] Improving Sitemap and Flowscript)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Improving Sitemap and Flowscript
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Gianugo Rabellino <gi...@apache.org>.
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: Writing for users
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Gianugo Rabellino wrote:
> 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?
I share your concerns, and my proposal was actually more about the
abilities of this kind of component than its naming. So we can consider
using the "adapt-environment" sitemap statement using components
adapting a _subset_ of the environment, which is the object model.
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
Writing for users (was: Re: [RT] Improving Sitemap and Flowscript)
Posted by Gianugo Rabellino <gi...@apache.org>.
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
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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.
>
>
> ahhhhh, 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
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
ahhhhh, 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
Posted by Gianugo Rabellino <gi...@apache.org>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 20, 2003, at 20:15 Europe/Rome, Gianugo Rabellino
wrote:
> Looks like I missed some serious fun during these vacations... time to
> catch up!
>
> Stefano Mazzocchi wrote:
>> Virtual Pipeline Components
>> ---------------------------
>
> Love the idea. Even because it was me suggesting something like that a
> couple of years ago and being blamed of FS... ;-)
Really? any pointer? (I'm not being sarcastic, but curious... if I
judged FS something that I later ended up proposing, there is something
wrong in my FS meter ;-)
>> Moving Sitemap components into cocoon.xconf
>> -------------------------------------------
>> the default sitemap is too verbose and this scares people away. I
>> would like to move the default sitemap component definitions into the
>> cocoon.xconf.
>
> Correct analysis, but I'm not sure about the solution: I still think
> that components belong to the sitemap, and I tend to agree with Jay's
> suggestion to provide a base.xmap with component declarations and a
> sitemap.xmap with just pipelines.
Yes, I think this is a better solution.
>> Pluggable Request Factories
>> ---------------------------
>> Cocoon needs a simple way to deal with complex HTTP usages, such as
>> binary uploading, XML-RPC, WebDAV or SOAP.
>> After a lot of discussion with Sylvain and input from many other
>> people, I propose the introduction of a new sitemap element named
>> "map:adaptRequest" that works by adapting the Request object into a
>> more specific object that will parse the request and provide
>> API-level access to the request.
>
> Hmmm... need serious thinking here, a drawing board and some coffee.
> But here are a couple of eurocents:
>
> 1. I don't like the "adaptRequest" name, it's a bit inconsistent with
> other sitemap semantics: I'd go for "adapt-request" instead;
Ok
> 2. Are you sure that adapting the request is enough?
I couldn't come up with anything that required more than that.
> I'd say that the different use cases you're pointing out require a bit
> more then just the request object: I'd say that the whole environment
> might need a particular treatment in most cases.
Why so, can you elaborate? maybe with a specific example? scenarios
help the design.
>> Interception in Flowscript
>> ----------------------------
>> Adding interception mechanism to the flowscript requires three
>> changes, two in the FOM, one (more important!) in the javascript
>> syntax:
>
> Very interesting, even if, as Christian points out correctly, the AAA
> sample of yours might be done too using an action. Or even (hacky?)
> with nested flow calls:
>
> <match pattern="myapp">
> <call function="checklogin"/>
> </match>
>
> <match pattern="myapp/protected">
> <call function="main"/>
> </match>
>
> <match pattern="myapp/login">
> <call function="login"/>
> </match>
>
> with "checklogin" being just a switchboard function redirecting to
> either "myapp/protected" or "myapp/login".
No, interception allows you to remove and compose aspects without
requiring to rewrite any part of the code (only the section that
identifies the intercepting patterns to apply).
I agree that actions, in this sense, are more orthogonal. Will reply to
Christian in more detail on this.
> But interception is way more than this, so I'd just love to have a bit
> of AOP in Cocoon flow. However, this brings me back to my pet peeve:
> adding such functionality on Rhino screams for a merge of our patches
> before even thinking of it. AOP in Javascript... how cool!
Keep in mind that interception is not AOP, only one of the possible way
to decompose a program into orthogonal layers that can be applied and
removed. To me, it feels more like SoC at intra-function scripting
level than anything else.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Gianugo Rabellino <gi...@apache.org>.
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:
<match pattern="myapp">
<call function="checklogin"/>
</match>
<match pattern="myapp/protected">
<call function="main"/>
</match>
<match pattern="myapp/login">
<call function="login"/>
</match>
with "checklogin" being just a switchboard function redirecting to
either "myapp/protected" or "myapp/login".
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
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Tony Collen wrote:
<snip/>
> 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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Tony Collen <co...@umn.edu>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Miles Elam <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> I propose the creation of "virtual pipeline components" by aggregating
> two or more components into a virtual one.
Love it. Love it. Love it!
> Moving Sitemap components into cocoon.xconf
> -------------------------------------------
>
> the default sitemap is too verbose and this scares people away. I
> would like to move the default sitemap component definitions into the
> cocoon.xconf.
>
> Note that with blocks, the definitions of those components will be in
> the block.xconf as well and this will be aggregated by the block manager.
Except for the fact that cocoon.xconf is too verbose and this scares
people away. While for the most part the contents of cocoon.xconf have
no direct impact on the sitemap, the components are intimately tied.
What is the problem with specifying a new file like "components.xconf"
or specifying it in the sitemap? For example
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:components src="components.xconf"/>
...
</map:sitemap>
Doesn't RelaxNG allow differing element content depending on attribute
value? (I think so.) This would allow validation for this example and
putting component definitions in the map:components element as it is today.
In other words, if the components are in the sitemap.xmap file, nothing
changes; But in the cases where having the components in a separate
file make sense, it is clear where these definitions are located. (An
often overlooked issue.)
Imagine this: A new user fires up Cocoon and wonders where the sitemap
components are defined or, more likely, wonders what sitemap components
are available. Off goes a question to the mailing list. (People don't
read docs, remember? ;-) An option here would be to add a comment here
to the effect of "Sitemap component definitions are in
WEB-INF/cocoon.xconf." So the newbie goes to cocoon.xconf and is
confronted with not just the sitemap component definitions, but all of
the components in use by the system and their configurations, roles,
etc. The complexity and intimidation is still there, just shifted off
to another file.
- or -
A new user fires up Cocoon and wonders where the components are defined
or, more likely, wonders what components are available. At the top of
the sitemap in the map:components element is a reference to the file
that contains the definitions (and only the definitions).
Am I completely off-base here?
> Pluggable Request Factories
> ---------------------------
>
> Cocoon needs a simple way to deal with complex HTTP usages, such as
> binary uploading, XML-RPC, WebDAV or SOAP.
Indeed.
> After a lot of discussion with Sylvain and input from many other
> people, I propose the introduction of a new sitemap element named
> "map:adaptRequest" that works by adapting the Request object into a
> more specific object that will parse the request and provide API-level
> access to the request.
Very nice!
> Interception in Flowscript
> ----------------------------
>
> While writing flowscripts, you realize how many things can be applied
> to many of the various flowscript functions that are called by the
> sitemap. In Linotype, I ended up using the ability that javascript
> gives you of using functions as native objects and then invoquing them
> by passing a modified argument vector.
>
> It came to me that what I did with linotype was a really-poor-man
> interception mechanism. Interception is the ability to "intercept" a
> method call and execute some code before or after the execution of the
> intercepted method.
Interesting...
> 1) the addition of a function call to the "cocoon" object, which
> indicates that intercepting function calls should be imported.
>
> cocoon.apply("blah.js");
>
> where "blah.js" contains the intercepting functions.
>
> 2) the addition of a function call to context that continues the
> intercepted invocation:
>
> ...
> continueExecution(arguments);
> ...
>
> 3) the introduction of wildcars for function names.
>
> function get*() {
> ...
> }
<snip-great-authorization-example />
Is only one interception possible? Authentication is one use case for
an interception. Authorization could be another. I'm sure there are
others. Would multiple calls to cocoon.apply(...) be possible? Would
they be order dependent?
Also, am I correct in the assumption that the wildcard is intended to
match target functions? Doesn't that tie the two files too closely
together? Or is this a change to the sitemap calling syntax. Does the
sitemap call getwhatever(...), a get* function intercepter catches it
and then eventually passes the call down to whatever(...)?
- Miles Elam
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Improving Sitemap and Flowscript
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 28/08/2003 17.27:
>
> On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi wrote:
>
>> >Calling a resource, inserting a virtual pipeline and using the
>> cocoon: protocol are for most uses equivalent.<
>
> I agree when you say that since the introduction of the cocoon:
> protocol, map:resource is now redundant (and less appealing, as well).
> In fact, we could go as far as saying that <map:resource> is no longer
> needed and could be deprecated.
>
> This would leave us only with pipelines, components and virtual
> components (which are, in fact, typed pipeline fragments), and the
> cocoon: protocol to mix them, if needed.
+1 from me for this
...
>> (I won't use AOP terminology that I personally don't yet like)
>>
>> >See, I don't like it too! ;-)<
>
> well, when you propose something like <map:aspects> it seems AOP-ish
> enough for me ;-) that's not coherent with the above.
Only the name "aspect". I refrained talking about pointcuts, advises,
etc... (ugh, I do hate those...)
>> So we can generalize it, and add configurability to the view mechanism
>> to specify other conditions.
>>
>> >Thus views effectively insert pipeline fragments at a certain
>> condition. In fact they insert their contents after a label.
>>
>> So the label is the condition.
>
> I know it's a matter of terminology pickyness, but I disagree. The
> condition that triggers the view is the view request. The result of this
> condition is the execution of the pipeline that is 'instrumented' to
> route its output somewhere else (to the view, which can now be seen as a
> virtual serializer)
Correct. You know how messy I am in describing things. Put the right
terminology instead of condition.
...
> you are using AOP the micro-granular way. This is: remove crosscutting
> by making all overlapping aspect objects and compose them together.
>
> I tend to dislike this practice since it leads, IMHO, to poor
> readability (users don't have the vision of crosscutting concerns that
> we developers do, and they perceive it as unnecessary overcomponentization)
>
> a critic to the above is: why would you want to gather-links if you are
> not going to serialize them?
Yes, I've come to the same conclusion yesterday too.
> You are suggesting that a more general aspect-oriented approach to
> pipeline composability might be general enough to allow views to be
> replaced by such a more powerful approach.
>
> I agree.
Ok.
> What I don't understand is why we should give away a perfectly fine
> system for a new flexibility we don't need. [note how I avoided to named
> this FS even if I was very tempted to do so ;-)]
;-)
Yes, I see this too now.
The RT started out of a link-gathering evolution, and for that only it
may be too much...
>> This would make it very easy to add security-based checks, logging, or
>> any other stuff.
>>
>> <map:aspects>
>> <map:aspect type="pipeline" test="start">
>> <map:action type="check-security"/>
>> </map:aspect>
>> <map:aspect type="pipeline" test="all">
>> <map:transformer type="logger"/>
>> </map:aspect>
>> <map:aspect type="error" test="all">
>> <map:action type="notify-admin"/>
>> </map:aspect>
>> </map:aspects>
>
> I don't like this and I don't see any reasonable use of the above system
> besides views. [c'mon, a logging aspect is much easier implemented by a
> different pipeline implementation, an admin-notifier is much better
> placed in a error-handler, where it belongs, and for flow-related
> actions, well, you know my opinion on those]
>
> What am I missing?
Simple: AOP does not make you do more things, it factorizes common
behaviours in a single place. If the places where these things must be
placed are a lot, then it makes sense, else it doesn't.
You have much more experience in seeing working systems, so you can
judge better than me on this.
...
>> *IMPORTANT* (and the reason why I started the RT):
>> So in he CLI, instead of asking for the link view and then generate, I
>> simply ask Cocoon to insert a transformer that gathers links in the
>> same positions where the links view would.
>>
>> This would make it possible for the CLI to have the configurability of
>> the view gatherer but the speed of the transfomer gatherer.
>
> This is probably the point I'm missing.
>
> Instead of discussion the solution, can't we start over again from the
> problem? maybe there are easier solutions that you didn't think about.
This is the last iteration of a looong discussion ;-)
Summary:
- CLI crawling link-views is slow
- it's slow because it's multipass
- make it monopass by instrumenting the pipeline with a gatherer
- this brings >50% speed increase
- but the instrumentation is not configurable:
- no place where to tell where ti gather
- no link filtering
- add a filter to the links (done in CVS)
- Vadim has the idea of using a tee instead
So let's leave this where it is now till some real need comes up, and
let's continue the thread from the last mail of Upayavira on this.
Below the last comments.
>> What do others think?
>>
>> Is it already possible to do this today with other components and
>> skillful pipeline writing?
>
> what do you mean with "this"?
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 mean, if I want to add something before all processing and after all
processing, I can simply make a match for **, that has something at the
beginning and something at the end, and inject the content in the middle.
To insert an action before and skinning after this:
match: **
generator: {1}
..(*)..
serializer: xml
I can do:
match: **
action: pre
generator: cocoon://internal/{1}
transformer: skin
serializer: html
match: internal/**
generator: {1}
..(*)..
serializer: xml
But I cannot insert anything inside ..(*)..
With aspects I can... conceded there is a need for it, of course.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote, On 28/08/2003 14.00:
>
>> Nicola Ken Barozzi wrote:
>> <snip/>
>>
>>> *IMPORTANT* (and the reason why I started the RT):
>>> So in he CLI, instead of asking for the link view and then generate,
>>> I simply ask Cocoon to insert a transformer that gathers links in
>>> the same positions where the links view would.
>>>
>>> This would make it possible for the CLI to have the configurability
>>> of the view gatherer but the speed of the transfomer gatherer.
>>
>>
>> Links view is not a transformer. It's a view, meaning that it can
>> have actions, matchers, selectors, transformers, and should end with
>> text serializer. So, you cannot simply add one transformer and think
>> that you are done with links view.
>
>
> When I say Transformer here I mean Virtual Transformer, that can be
> all you say above, as I suggest in the RT. This also means that this
> virtual Transformer can also do the link exclusion and other things
> that are needed and that a simple transformer cannot do.
>
>> In addition to this, adding a transformer would not work because this
>> alters pipeline cache key which prevents such legitimate CLI usages
>> as pre-populating persistent cache.
>
>
> I do not see the case in which this happens. Could you explain more
> please?
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:
<map:view name="links" from-label="content">
<map:transform src="links.xsl"/>
<map:serialize type="links"/>
</map:view>
<map:pipeline>
<map:generate src="data.xml"/>
<map:transform src="content.xsl" label="content"/>
<map:transform src="page.xsl"/>
<map:transform src="html.xsl"/>
<map:serialize type="html"/>
</map:pipeline>
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
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote, On 28/08/2003 14.00:
> Nicola Ken Barozzi wrote:
> <snip/>
>
>> *IMPORTANT* (and the reason why I started the RT):
>> So in he CLI, instead of asking for the link view and then generate, I
>> simply ask Cocoon to insert a transformer that gathers links in the
>> same positions where the links view would.
>>
>> This would make it possible for the CLI to have the configurability of
>> the view gatherer but the speed of the transfomer gatherer.
>
> Links view is not a transformer. It's a view, meaning that it can have
> actions, matchers, selectors, transformers, and should end with text
> serializer. So, you cannot simply add one transformer and think that you
> are done with links view.
When I say Transformer here I mean Virtual Transformer, that can be all
you say above, as I suggest in the RT. This also means that this virtual
Transformer can also do the link exclusion and other things that are
needed and that a simple transformer cannot do.
> In addition to this, adding a transformer
> would not work because this alters pipeline cache key which prevents
> such legitimate CLI usages as pre-populating persistent cache.
I do not see the case in which this happens. Could you explain more please?
> Solution to the CLI problem was already found (attach links view as a
> tee to main pipeline, see "Link View Goodness" on approx 2003/07/01)
http://marc.theaimsgroup.com/?l=xml-cocoon-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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Vadim Gritsenko <va...@verizon.net>.
Upayavira wrote:
> Vadim Gritsenko wrote:
>
>> Nicola Ken Barozzi wrote:
>> <snip/>
>>
>>> *IMPORTANT* (and the reason why I started the RT):
>>> So in he CLI, instead of asking for the link view and then generate,
>>> I simply ask Cocoon to insert a transformer that gathers links in
>>> the same positions where the links view would.
>>>
>>> This would make it possible for the CLI to have the configurability
>>> of the view gatherer but the speed of the transfomer gatherer.
>>
>>
>>
>> Links view is not a transformer. It's a view, meaning that it can
>> have actions, matchers, selectors, transformers, and should end with
>> text serializer. So, you cannot simply add one transformer and think
>> that you are done with links view.
>
>
> You are right - Nicola Ken is here mixing up Link View and Link
> Gathering - two different approaches. What he says though is relevant
> to the link gathering approach, i.e. that it could be implemented with
> an 'aspect' allowing the user to insert the gathering stage at any
> point in their pipeline, by attaching a gathering transformer to a
> label (defaulting to the last stage, just before the serializer).
Once we have links view working allright, we will kill link gathering
alltogether -- anyway it was just a hack ;-)
Vadim
Re: [RT] Improving Sitemap and Flowscript
Posted by Upayavira <uv...@upaya.co.uk>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
> <snip/>
>
>> *IMPORTANT* (and the reason why I started the RT):
>> So in he CLI, instead of asking for the link view and then generate,
>> I simply ask Cocoon to insert a transformer that gathers links in the
>> same positions where the links view would.
>>
>> This would make it possible for the CLI to have the configurability
>> of the view gatherer but the speed of the transfomer gatherer.
>
>
> Links view is not a transformer. It's a view, meaning that it can have
> actions, matchers, selectors, transformers, and should end with text
> serializer. So, you cannot simply add one transformer and think that
> you are done with links view.
You are right - Nicola Ken is here mixing up Link View and Link
Gathering - two different approaches. What he says though is relevant to
the link gathering approach, i.e. that it could be implemented with an
'aspect' allowing the user to insert the gathering stage at any point in
their pipeline, by attaching a gathering transformer to a label
(defaulting to the last stage, just before the serializer).
> In addition to this, adding a transformer would not work because this
> alters pipeline cache key which prevents such legitimate CLI usages as
> pre-populating persistent cache.
Interesting point. That would also apply to the link translator, which,
if confirm-extensions is used (which it is by default), is inserted
before the serializer. So, to be able to pre-populate a persistent
cache, you've got to (a) use link view (b) make sure you don't confirm
extensions.
> Solution to the CLI problem was already found (attach links view as a
> tee to main pipeline, see "Link View Goodness" on approx 2003/07/01)
> and Upayavira is looking into ways of implementing it. I would help
> him out but right now I can't.
Having reread Nicola Ken's post, I think I understood it this time
(rather than being confused by all the references to aspects as I was
last time).
He does propose an interesting and more generic way to achieve what
Vadim has already suggested - using an XML Tee component to feed SAX
events into two pipeline segments simultaneously. To do that hard coded
would be hard, and require quite a bit of work within
AbstractProcessingPipeline. Doing it in Nicola Ken's way strikes me as
cleaner and more generic. So you'd be able to add 'aspects' that use
generators/transformers/serializers in the following combinations:
1) G-T-S (pretty useless as it doesn't really interact with the pipeline
as it is)
2) T-S (takes the current SAX events, using a Tee, and feeds them to a
section of pipeline that serializes somewhere else - e.g. link view)
3) G-T (replaces or augments SAX events with an additional source)
4) T (transforms existing SAX events, e.g. link gatherer)
So we get a generic way of implementing our two gathering methods, and
probably some additional methods we hadn't thought of.
In case 2), we'd probably want to have another component after the
serializer which defines what to do with the content, e.g. an
ObjectModelWriter that writes it to the ObjectModel, a FileWriter that
writes it to a file (or more likely a SourceWriter).
Does this make sense? Or is it barking? (barking is shorthand for
'barking mad', like wild dogs can be sometimes).
Regards, Upayavira
Re: [RT] Improving Sitemap and Flowscript
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
<snip/>
> *IMPORTANT* (and the reason why I started the RT):
> So in he CLI, instead of asking for the link view and then generate, I
> simply ask Cocoon to insert a transformer that gathers links in the
> same positions where the links view would.
>
> This would make it possible for the CLI to have the configurability of
> the view gatherer but the speed of the transfomer gatherer.
Links view is not a transformer. It's a view, meaning that it can have
actions, matchers, selectors, transformers, and should end with text
serializer. So, you cannot simply add one transformer and think that you
are done with links view. In addition to this, adding a transformer
would not work because this alters pipeline cache key which prevents
such legitimate CLI usages as pre-populating persistent cache.
Solution to the CLI problem was already found (attach links view as a
tee to main pipeline, see "Link View Goodness" on approx 2003/07/01) and
Upayavira is looking into ways of implementing it. I would help him out
but right now I can't.
Vadim
Re: [RT] Improving Sitemap and Flowscript
Posted by Upayavira <uv...@upaya.co.uk>.
Stefano,
<lots of stuff snipped/>
>> *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
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 27, 2003, at 17:41 Europe/Rome, Nicola Ken Barozzi
wrote:
> >Calling a resource, inserting a virtual pipeline and using the
> cocoon: protocol are for most uses equivalent.<
I agree when you say that since the introduction of the cocoon:
protocol, map:resource is now redundant (and less appealing, as well).
In fact, we could go as far as saying that <map:resource> is no longer
needed and could be deprecated.
This would leave us only with pipelines, components and virtual
components (which are, in fact, typed pipeline fragments), and the
cocoon: protocol to mix them, if needed.
> What remains is the <views> part, that has introduced pipeline-stage
> metadata, as a label. It's an aspect that gets called when that
> particular condition is met
>
> >IOW, I'm rephrasing, using different terminology, that a view is an
> orthogonal mechanism, that interacts with the normal sitemap using
> some metadata and an exit pipeline.
> The labels are effectively metadata, as they describe the pipeline.
> The exit pipelines, ie the views themselves, are what has to be done.
> <
Yes, views are orthogonal pipelines.
> (I won't use AOP terminology that I personally don't yet like)
>
> >See, I don't like it too! ;-)<
well, when you propose something like <map:aspects> it seems AOP-ish
enough for me ;-) that's not coherent with the above.
> So we can generalize it, and add configurability to the view mechanism
> to specify other conditions.
>
> >Thus views effectively insert pipeline fragments at a certain
> condition. In fact they insert their contents after a label.
>
> So the label is the condition.
I know it's a matter of terminology pickyness, but I disagree. The
condition that triggers the view is the view request. The result of
this condition is the execution of the pipeline that is 'instrumented'
to route its output somewhere else (to the view, which can now be seen
as a virtual serializer)
> *first proposal*
> I propose that we define other conditions.<
>
> <map:view name="content" from-label="content">
> <map:serialize type="xml"/>
> </map:view>
>
> becomes:
>
> <map:view name="content" type="from-label"
> test="content">
> <map:serialize type="xml"/>
> </map:view>
>
> This makes it possible to make a different position where to start
> from...
> What can also be made configurable is *when*, in which condition, it's
> triggered, but the logic has to be inverted.
>
> >What I mean here is that views are triggered only by the user. Normal
> results are done *without* calling views. So if I want to say: insert
> a logger after each generator, I cannot do it easily, as I would have
> to call a "logger-view" for it to be called. And I would have only one
> possible insertion per pipeline, as only one view is called at a > time.<
ok, now I get it
> Now we say: "when the view is triggered, start at a label"
> After it could be: "when the view is triggered, start at position"
> Instead we need: "when the position is met, check if it has to be
> triggered".
>
> Here is an example that uses this "inverted" AOPish system for views.
>
> >Let me rephrase this: the following is a way of defining views in a
> more generic way. Here I don't say anymore: "when the user asks for a
> view trigger the label (or more generic as in the first proposal)
> condition", but "at every stage check if a condition is met, and if so
> execute the "generalized view".
hmmmmm
> *second proposal*
> Make it possible to tell Cocoon to add pipeline snippets (ie virtual
> pipelines) given certain rules. This makes it possible to have views
> be made with this more generic mechanism.
> <
>
> The following adds two aspects:
> - an aspect gets called from every content position and gathers
> links.
> - the other one gets called from every content position. If the
> request has a cocoon-view=links, then the links are serialized.
> <map:aspects>
> <map:aspect type="from-label" test="content">
> <!-- Any required link munging -->
> <map:transformer type="gather-links"/>
> </map:aspect>
> <map:aspect type="from-label" test="content">
> <map:action type="request-param">
> <map:param name="cocoon-view" value="link">
> <map:serializer type="links"/>
> </map:action>
> </map:aspect>
> </map:aspects>
you are using AOP the micro-granular way. This is: remove crosscutting
by making all overlapping aspect objects and compose them together.
I tend to dislike this practice since it leads, IMHO, to poor
readability (users don't have the vision of crosscutting concerns that
we developers do, and they perceive it as unnecessary
overcomponentization)
a critic to the above is: why would you want to gather-links if you are
not going to serialize them?
You are suggesting that a more general aspect-oriented approach to
pipeline composability might be general enough to allow views to be
replaced by such a more powerful approach.
I agree.
What I don't understand is why we should give away a perfectly fine
system for a new flexibility we don't need. [note how I avoided to
named this FS even if I was very tempted to do so ;-)]
> This would make it very easy to add security-based checks, logging, or
> any other stuff.
>
> <map:aspects>
> <map:aspect type="pipeline" test="start">
> <map:action type="check-security"/>
> </map:aspect>
> <map:aspect type="pipeline" test="all">
> <map:transformer type="logger"/>
> </map:aspect>
> <map:aspect type="error" test="all">
> <map:action type="notify-admin"/>
> </map:aspect>
> </map:aspects>
I don't like this and I don't see any reasonable use of the above
system besides views. [c'mon, a logging aspect is much easier
implemented by a different pipeline implementation, an admin-notifier
is much better placed in a error-handler, where it belongs, and for
flow-related actions, well, you know my opinion on those]
What am I missing?
> >
> With virtual pipelines (vp) we could as well do:
>
> <map:aspects>
> <!-- if the "from-label" condition of the current pipeline component
> matches "content", then insert right after it the virtual
> pipeline called gather-links and content-view.
> IOW add a link gatherer and a link view after each content
> labeled component.-->
> <map:aspect type="from-label" test="content" vp="gather-links"/>
> <map:aspect type="from-label" test="content" vp="content-view"/>
>
> <!-- if the "pipeline" condition of the current pipeline component
> matches "start", then insert right after it the virtual
> pipeline called check-security.
> IOW add a security check at each pipeline start.-->
> <map:aspect type="pipeline" test="start" vp="check-security"/>
>
> <!-- if the "pipeline" condition of the current pipeline component
> matches "all", then insert right after it the virtual
> pipeline called logger.
> IOW add a logger after each component.-->
> <map:aspect type="pipeline" test="all" vp="logger"/>
>
> <!-- if the "error" condition of the current pipeline component
> matches "all", then insert right after it the virtual
> pipeline called check-security.
> IOW notify the admin when the error pipeline gets called.-->
> <map:aspect type="error" test="all" vp="notify-admin"/>
>
> </map:aspects>
>
>
> 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.
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.
> 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"?
> 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.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 26/08/2003 18.43:
...
> I would like Nicola to update its RT on aspectizing the sitemap after
> the introduction of virtual components (which, IMO, solve most of the
> issues he outlined).
Actually I already reference the concept:
"Hmmm, it also has to do with the "named pipelines" thread, or the
pipeline==reusable_component one that Stefano had started."
But I don't see a real direct benefit of virtual components in this RT
yet as it's not the main point it seems to me.
> What is not covered, IMO, can be implemented by
> extending the view concept.
Which is basically what the while RT is about IMHO. I see how things
work now, how the view concept can be extended, and then how
"aspectized" pipelines can be a bigger generalization of views.
Below is the salient part of the RT with additions and comments in
>brackets<
>Now I describe the current situation<
- <pipelines> are called per request one after the other till the
sitemap exits
- <resources> are sitemap snippets called by the pipelines
- <views> are exit points that get called at a particular label
(effectively a hard-wired AOP feature) by the sitemap
Pipelines and resources are effectively the same thing not that there is
the cocoon protocol.
>Calling a resource, inserting a virtual pipeline and using the cocoon:
protocol are for most uses equivalent.<
What remains is the <views> part, that has introduced pipeline-stage
metadata, as a label. It's an aspect that gets called when that
particular condition is met
>IOW, I'm rephrasing, using different terminology, that a view is an
orthogonal mechanism, that interacts with the normal sitemap using some
metadata and an exit pipeline.
The labels are effectively metadata, as they describe the pipeline.
The exit pipelines, ie the views themselves, are what has to be done.
<
(I won't use AOP terminology that I personally don't yet like)
>See, I don't like it too! ;-)<
So we can generalize it, and add configurability to the view mechanism
to specify other conditions.
>Thus views effectively insert pipeline fragments at a certain
condition. In fact they insert their contents after a label.
So the label is the condition.
*first proposal*
I propose that we define other conditions.<
<map:view name="content" from-label="content">
<map:serialize type="xml"/>
</map:view>
becomes:
<map:view name="content" type="from-label"
test="content">
<map:serialize type="xml"/>
</map:view>
This makes it possible to make a different position where to start from...
What can also be made configurable is *when*, in which condition, it's
triggered, but the logic has to be inverted.
>What I mean here is that views are triggered only by the user. Normal
results are done *without* calling views. So if I want to say: insert a
logger after each generator, I cannot do it easily, as I would have to
call a "logger-view" for it to be called. And I would have only one
possible insertion per pipeline, as only one view is called at a time.<
Now we say: "when the view is triggered, start at a label"
After it could be: "when the view is triggered, start at position"
Instead we need: "when the position is met, check if it has to be
triggered".
Here is an example that uses this "inverted" AOPish system for views.
>Let me rephrase this: the following is a way of defining views in a
more generic way. Here I don't say anymore: "when the user asks for a
view trigger the label (or more generic as in the first proposal)
condition", but "at every stage check if a condition is met, and if so
execute the "generalized view".
*second proposal*
Make it possible to tell Cocoon to add pipeline snippets (ie virtual
pipelines) given certain rules. This makes it possible to have views be
made with this more generic mechanism.
<
The following adds two aspects:
- an aspect gets called from every content position and gathers links.
- the other one gets called from every content position. If the
request has a cocoon-view=links, then the links are serialized.
<map:aspects>
<map:aspect type="from-label" test="content">
<!-- Any required link munging -->
<map:transformer type="gather-links"/>
</map:aspect>
<map:aspect type="from-label" test="content">
<map:action type="request-param">
<map:param name="cocoon-view" value="link">
<map:serializer type="links"/>
</map:action>
</map:aspect>
</map:aspects>
This would make it very easy to add security-based checks, logging, or
any other stuff.
<map:aspects>
<map:aspect type="pipeline" test="start">
<map:action type="check-security"/>
</map:aspect>
<map:aspect type="pipeline" test="all">
<map:transformer type="logger"/>
</map:aspect>
<map:aspect type="error" test="all">
<map:action type="notify-admin"/>
</map:aspect>
</map:aspects>
>
With virtual pipelines (vp) we could as well do:
<map:aspects>
<!-- if the "from-label" condition of the current pipeline component
matches "content", then insert right after it the virtual
pipeline called gather-links and content-view.
IOW add a link gatherer and a link view after each content
labeled component.-->
<map:aspect type="from-label" test="content" vp="gather-links"/>
<map:aspect type="from-label" test="content" vp="content-view"/>
<!-- if the "pipeline" condition of the current pipeline component
matches "start", then insert right after it the virtual
pipeline called check-security.
IOW add a security check at each pipeline start.-->
<map:aspect type="pipeline" test="start" vp="check-security"/>
<!-- if the "pipeline" condition of the current pipeline component
matches "all", then insert right after it the virtual
pipeline called logger.
IOW add a logger after each component.-->
<map:aspect type="pipeline" test="all" vp="logger"/>
<!-- if the "error" condition of the current pipeline component
matches "all", then insert right after it the virtual
pipeline called check-security.
IOW notify the admin when the error pipeline gets called.-->
<map:aspect type="error" test="all" vp="notify-admin"/>
</map:aspects>
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 Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
RE: [RT] Improving Sitemap and Flowscript
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
used by the flow is *NOT* a concern of the flow itself, but a property
of the context in which the flow is executed. For this reason, it can
be implemented as interception.
Example of this are:
1) connection pool control
2) object persistence control
3) external cache invalidation control (for example, a transparent
proxy might be signaled to reload a resource)
3) monitoring
the creation of events that are not directly related to a flow but
rather to its invocation. Examples of this are:
a) logging
b) debugging/tracing
c) profiling
d) concurrency analysis
e) user profilation
4) context augmentation
when flow's behavior can be further specified by contextual data that
might be defaulted if not present. Examples of this are:
a) user authentication
b) user personal parameters (style, mode, profile)
So, even if our users won't be more creative than I am (and I strongly
doubt it!) things are already juicy enough, IMO, to provide a reason to
implement interception in cocoon's flow.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Improving Sitemap and Flowscript
Posted by Gianugo Rabellino <gi...@apache.org>.
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
Posted by Boon Hian Tek <bt...@pdxbtek.dyndns.org>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
On Sunday, Aug 24, 2003, at 17:58 Europe/Rome, Steven Noels wrote:
> Stefano Mazzocchi wrote:
>
>> One day I hope the anti-flow/pro-action people will simply stop
>> sneaking doubts and come up with real arguments on why we shouldn't
>> heavily bet on the flow.
>
> I thought we were done with this balkanization thing, didn't we? I for
> one have just finished my first tiny flow-based application, and while
> I still find the edge layer where Java & Javascript meet each other
> quite murky, I had good fun while hacking on it. It's not about just
> black & white, Stefano.
The edges are rough. I cannot agree more. But this is *exactly* why I'm
working hard in designing ways to polishing those edges without making
anything else rougher.
Anyway, criticizing keeps use flow-lovers honest and with feet on the
ground, so keep it up.
> <dreaming>
> What I would like to see, even if some of it might be nonsense, is a
> seriously integrated scripting environment to code the behaviour of a
> webapp, and flowscript is a nice way to start exploring that concept.
> With serious, I mean there should be a way to work with persistency,
> security, and back-end business logic without this stupid Packages
> thing, and, because of the continuous bouncing back & forward between
> Java and JS, not having to worry about the automagic typecasting that
> happens on the border between Java & Javascript.
I hate the "Packages" syntax as much as you do, believe me. But with
real blocks, you will do
var component = cocoon.getComponent(..);
after having deployed your block live and you'll automagically get what
you want (with implicit versioning and all that).
It will be the *real* dream of avalon finally coming true, versioned
hotdeploying of components cannot be given by no technology out there
(only .NET has such a concept, but they don't have continuations!)
> Syntax-wise, I have about the same problem with JS as I have with
> Java, but that's because I find Python a tad more readible. There's
> people around here that would rather like to code flow in real Java,
> with dynamic recompilation and all that. There's room for diversity,
> and we should exploit that. Even Apples hooks in with the flow at some
> point. <aside>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?</aside>
What does the above have to do with adding interception to the flow?
> We should work on serious JS-wrapping of services typically used in
> webapps, and extensive Avalonization of existing Cocoon code can help
> with that. There should be formalization of the border area between
> Java & JS, or we will kill ourselves with recurring user questions
> about the lack of explicit semantics & casting.
I totally agree, but again, this cannot work without blocks.
[and it seems that nobody is catching up with my plan for
implementation so I will have to get my hands dirty and implement the
whole thing by myself, :-(
> Over time, I still hope that some Jython guru will pop up and make all
> this also possible using a language I've come to appreciate above JS,
> but that's entirely IMHO.
once you have a way to add continuations in java, you can have your
jython thing for free.
> </dreaming>
>
> Of course, if we start from a discours of "either you're with us, or
> you're against us", well, all this might take a long time to happen.
> As much as you repeatedly come back on this so-called split between
> pro and contra, I'm quite sure that you are currently misguiding
> yourself (and through such remarks, also this community) about this
> so-called polarization. For myself, I started hating overweight
> sitemaps a long time ago. I'm also pretty sure some of the old
> action-farts will be amongst the people who, eventually, will make
> sure flowscript reaches the same level of robustness, documentation
> and user support that the 'old stuff' already has.
As I said, costructive criticism helps to keep people honest and I
appreciate that.
I just happen to be a little nervous when I hear comments that don't
look costructive. And yes, I might be too sensible on the issue, given
the past discussions.
> Oh, and I did read the rest of your mail, and you were right about
> AAA, interceptors and flow. I understand now. Thanks for your repeated
> efforts in educating the clueless. ;-D
When we add interception to a flowscript with continuations, we'll be
so much ahead of the current state of the art that people will need a
time machine to understand what we are talking about.
For this reason, I'm prepared to stand against years of people's
inertia on radical paradigm changes, so I wouldn't say "clueless", I
would just say "inertial".
But I have seen too many faces "illuminated" by the continuations
concepts. I can only wonder what continuations and interception,
together, can do to them ;-)
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> One day I hope the anti-flow/pro-action people will simply stop sneaking
> doubts and come up with real arguments on why we shouldn't heavily bet
> on the flow.
I thought we were done with this balkanization thing, didn't we? I for
one have just finished my first tiny flow-based application, and while I
still find the edge layer where Java & Javascript meet each other quite
murky, I had good fun while hacking on it. It's not about just black &
white, Stefano.
<dreaming>
What I would like to see, even if some of it might be nonsense, is a
seriously integrated scripting environment to code the behaviour of a
webapp, and flowscript is a nice way to start exploring that concept.
With serious, I mean there should be a way to work with persistency,
security, and back-end business logic without this stupid Packages
thing, and, because of the continuous bouncing back & forward between
Java and JS, not having to worry about the automagic typecasting that
happens on the border between Java & Javascript.
Syntax-wise, I have about the same problem with JS as I have with Java,
but that's because I find Python a tad more readible. There's people
around here that would rather like to code flow in real Java, with
dynamic recompilation and all that. There's room for diversity, and we
should exploit that. Even Apples hooks in with the flow at some point.
<aside>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?</aside>
We should work on serious JS-wrapping of services typically used in
webapps, and extensive Avalonization of existing Cocoon code can help
with that. There should be formalization of the border area between Java
& JS, or we will kill ourselves with recurring user questions about the
lack of explicit semantics & casting.
Over time, I still hope that some Jython guru will pop up and make all
this also possible using a language I've come to appreciate above JS,
but that's entirely IMHO.
</dreaming>
Of course, if we start from a discours of "either you're with us, or
you're against us", well, all this might take a long time to happen. As
much as you repeatedly come back on this so-called split between pro and
contra, I'm quite sure that you are currently misguiding yourself (and
through such remarks, also this community) about this so-called
polarization. For myself, I started hating overweight sitemaps a long
time ago. I'm also pretty sure some of the old action-farts will be
amongst the people who, eventually, will make sure flowscript reaches
the same level of robustness, documentation and user support that the
'old stuff' already has.
Oh, and I did read the rest of your mail, and you were right about AAA,
interceptors and flow. I understand now. Thanks for your repeated
efforts in educating the clueless. ;-D
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> If you talk to os kernel folks, they think authentication should happen
> right at TCP/IP stack level, if you talk to httpd, they will give you an
> apache module, if you talk to servlet engine folks, they will give you a
> web.xml descriptor or, if you are lucky, a servlet filter, if you talk
> to sitemap lovers, they will give you an action.
Out-of-the-blue-thought (and I had way too much wine last night):
shouldn't this 'action-in-sitemap' thing be alleviated by an
'orthogonal-to-the-matchers' thing in the sitemap? So that you end up
with a section in the sitemap describing the content-generating
artefacts, and another one listing the authentication realms, maybe
using the same matcher-like constructs describing which portions of the
URI space should be protected?
I'm having the slight feeling we are moving stuff into flowscript that
can mess up good URI practices.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:
>> I know, actions are not liked by everyone, but this is one of the best
>> applications for them.
>
>
> are you suggesting we don't think about adding interception in flow
> because otherwise this would kill the only place where actions have a
> reason to exist?
>
>> So, please provide a more convincing use case for the introduction of
>> AOP in Cocoon ;-)
Yawn... ;-)
I still believe authentication code should be orthogonal to actual
application logic, and rather be defined by the container. In this
discussion, I think 'sitemap' == 'container'. Also, since
authentication-requiring realms are a part of the overall URI namespace,
when finding out which parts need authentication, I would check first
with the container (web.xml) -> sitemap.xmap -> flowscript.
Not making authentication handling part of your application is one of
the first things I learned over here, when greeting Giacomo at ApacheCon
in London.
So, if you guys are talking about authentication with actions vs
flowscript & interceptors, what are you talking about: doing the
authentication, or checking authorization?
I'm curious and want to understand better.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
On Tuesday, Aug 19, 2003, at 22:41 Europe/Rome, Christian Haul wrote:
> Stefano Mazzocchi wrote:
>> Virtual Pipeline Components
>> ---------------------------
>
> <snip what="suggestions I agree with"/>
>
> I'm all in favour of this since the topic came up first. Unfortunatly,
> I haven't found the time investigating an implementation but I believe
> this should be straight forward.
>
> Although we're not (yet) discussing implementation details, I would
> like to suggest to wrap those pipeline fragments as Avalon components.
> I believe this will become handy with blocks as we only need to expose
> components from a block....
>
>> Moving Sitemap components into cocoon.xconf
>> -------------------------------------------
>> the default sitemap is too verbose and this scares people away. I
>> would like to move the default sitemap component definitions into the
>> cocoon.xconf.
>> Note that with blocks, the definitions of those components will be in
>> the block.xconf as well and this will be aggregated by the block
>> manager.
>
> We had this already at some time. Cutting the complexity is good.
> Perhaps we should follow the idea of splitting cocoon.xconf and root
> sitemap.xmap into two files each, one for the defaults and one (empty)
> for customization.
>
>
>> Pluggable Request Factories
>> ---------------------------
>
> <snip/>
>
> OK
>
>> Interception in Flowscript
>> ----------------------------
>> While writing flowscripts, you realize how many things can be applied
>> to many of the various flowscript functions that are called by the
>> sitemap. In Linotype, I ended up using the ability that javascript
>> gives you of using functions as native objects and then invoquing
>> them by passing a modified argument vector.
>> It came to me that what I did with linotype was a really-poor-man
>> interception mechanism. Interception is the ability to "intercept" a
>> method call and execute some code before or after the execution of
>> the intercepted method.
>> Interception is the simplest form of the aspect orientation.
>> Adding interception mechanism to the flowscript requires three
>> changes, two in the FOM, one (more important!) in the javascript
>> syntax:
>> 1) the addition of a function call to the "cocoon" object, which
>> indicates that intercepting function calls should be imported.
>> cocoon.apply("blah.js");
>> where "blah.js" contains the intercepting functions.
>> 2) the addition of a function call to context that continues the
>> intercepted invocation:
>> ...
>> continueExecution(arguments);
>> ...
>> 3) the introduction of wildcars for function names.
>> function get*() {
>> ...
>> }
>> the above seems rather accademic, so allow me to write an example
>> where the use of aspect-oriented flowscript would shine.
>> Something that can be modelled very well as an aspect is
>> authentication/authorization (aka login) because it's not something
>> that is part of the webapp (at least, it shouldn't be!) but it's
>> something that is "wrapped" around it to allow people to access it
>> without the proper authorization.
>
> Here I like to disagree, sort of. While I agree that authentication is
> a good use case for AOP, I don't come to the same conclusion. In fact,
> by using an action to protect a complete URI space very much the same
> can be achieved.
true
> I know, actions are not liked by everyone, but this is one of the best
> applications for them.
are you suggesting we don't think about adding interception in flow
because otherwise this would kill the only place where actions have a
reason to exist?
> So, please provide a more convincing use case for the introduction of
> AOP in Cocoon ;-)
Actions can be used as interceptors. It's not their only ability, but
yes, it's possible and good actions do perform this way.
So, any use case that requires action-based interception, will work as
nicely with flow interception.
What would we gain?
1) action-based interception is a concern of the flow layer, not of the
pipeline definition. i will never stop saying this, but actions should
not exist in the sitemap realm, since they mix concerns.
2) actions have a terribly poor error handling capability, even when
used as interceptors, flow-based interception keeps all the
functionality available at the flow level.
3) actions are hardcoded in the sitemap pipelines definitions.
flow-based interception will allow to wrap existing code without
needing to modify it or it will be possible to "remove" or modify
interception without modifying the original flow code.
I'll think about more juicy use cases tonight.
--
Stefano.
Interception in Flowscript (was: [RT] Improving Sitemap and Flowscript)
Posted by Reinhard Pötz <re...@apache.org>.
From: Christian Haul [mailto:haul@informatik.tu-darmstadt.de]
> > Interception in Flowscript
> > ----------------------------
> > Something that can be modelled very well as an aspect is
> > authentication/authorization (aka login) because it's not
> something that
> > is part of the webapp (at least, it shouldn't be!) but it's
> something
> > that is "wrapped" around it to allow people to access it
> without the
> > proper authorization.
>
> Here I like to disagree, sort of. While I agree that
> authentication is a
> good use case for AOP, I don't come to the same conclusion.
> In fact, by
> using an action to protect a complete URI space very much the
> same can
> be achieved. I know, actions are not liked by everyone, but
> this is one
> of the best applications for them.
>
> So, please provide a more convincing use case for the introduction of
> AOP in Cocoon ;-)
(Warning: the concept of AOP is rather new to me ...)
When we polished the FOM some weeks ago we talked a lot about
- pooled components
I think AOP would be a great advantage because I only have to
implement it once to get a Hibernate session and releasing it.
Other use cases are
- customized flows that have user exits without having to change
the core flow
- maybe error handling
- logging
- ... and of course authentication/authorization because I like to
have it within the flow because IMHO applications are very easy
to understand if the whole logic can be found at a single place.
I think these are some good reasons and worth of thinking more about
integrating AOP in flow.
Cheers,
Reinhard
Re: [RT] Improving Sitemap and Flowscript
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Stefano Mazzocchi wrote:
>
> Virtual Pipeline Components
> ---------------------------
<snip what="suggestions I agree with"/>
I'm all in favour of this since the topic came up first. Unfortunatly, I
haven't found the time investigating an implementation but I believe
this should be straight forward.
Although we're not (yet) discussing implementation details, I would like
to suggest to wrap those pipeline fragments as Avalon components. I
believe this will become handy with blocks as we only need to expose
components from a block....
> Moving Sitemap components into cocoon.xconf
> -------------------------------------------
>
> the default sitemap is too verbose and this scares people away. I would
> like to move the default sitemap component definitions into the
> cocoon.xconf.
>
> Note that with blocks, the definitions of those components will be in
> the block.xconf as well and this will be aggregated by the block manager.
We had this already at some time. Cutting the complexity is good.
Perhaps we should follow the idea of splitting cocoon.xconf and root
sitemap.xmap into two files each, one for the defaults and one (empty)
for customization.
> Pluggable Request Factories
> ---------------------------
<snip/>
OK
> Interception in Flowscript
> ----------------------------
>
> While writing flowscripts, you realize how many things can be applied to
> many of the various flowscript functions that are called by the sitemap.
> In Linotype, I ended up using the ability that javascript gives you of
> using functions as native objects and then invoquing them by passing a
> modified argument vector.
>
> It came to me that what I did with linotype was a really-poor-man
> interception mechanism. Interception is the ability to "intercept" a
> method call and execute some code before or after the execution of the
> intercepted method.
>
> Interception is the simplest form of the aspect orientation.
>
> Adding interception mechanism to the flowscript requires three changes,
> two in the FOM, one (more important!) in the javascript syntax:
>
> 1) the addition of a function call to the "cocoon" object, which
> indicates that intercepting function calls should be imported.
>
> cocoon.apply("blah.js");
>
> where "blah.js" contains the intercepting functions.
>
> 2) the addition of a function call to context that continues the
> intercepted invocation:
>
> ...
> continueExecution(arguments);
> ...
>
> 3) the introduction of wildcars for function names.
>
> function get*() {
> ...
> }
>
> the above seems rather accademic, so allow me to write an example where
> the use of aspect-oriented flowscript would shine.
>
> Something that can be modelled very well as an aspect is
> authentication/authorization (aka login) because it's not something that
> is part of the webapp (at least, it shouldn't be!) but it's something
> that is "wrapped" around it to allow people to access it without the
> proper authorization.
Here I like to disagree, sort of. While I agree that authentication is a
good use case for AOP, I don't come to the same conclusion. In fact, by
using an action to protect a complete URI space very much the same can
be achieved. I know, actions are not liked by everyone, but this is one
of the best applications for them.
So, please provide a more convincing use case for the introduction of
AOP in Cocoon ;-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Developing a block
Posted by Steve K <sh...@myrealbox.com>.
> everything you write down here looks ok
> (and confirmed by your own remark that it even works!)
Thank you for the reply. Also, I just noticed that the build file that
blocks-build.xsl only jars "org/**" classes -- this was a problem for me as
my java classes are in the com.* package. I had to edit the file to fix
this.
cheers,
-steve
Re: Developing a block
Posted by Marc Portier <mp...@outerthought.org>.
Steve,
everything you write down here looks ok
(and confirmed by your own remark that it even works!)
hot-deploy in my experience works ok as long as none of the
changes include class files or jars that need to be reloaded
just for completeness:
- 'real blocks' will be added in 2.2, that will change some stuff
for sure, see:
http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and a
recent RT posting:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106134587016684&w=2
- an alternative (while using similar techniques and having
different benfits/downsides) approach to writing your own block
in order to make a cocoon based app is here:
http://wiki.cocoondev.org/Wiki.jsp?page=YourCocoonBasedProject
HTH,
-marc=
Steve K wrote:
> Hey folks --
>
> I'm starting a new Cocoon application and I want to try to take advantage of
> the new 2.1 build system and the blocks stuff. As I couldn't find any
> documentation on how to do this, I put together something and wanted to run
> it by all of you to let me know if I'm on the right track. I added the
> following directory structure to the src/blocks dir:
>
> testblock/
> conf/
> testblock.xmap
> java/
> lib/
> webapp/
> testblock/
> sitemap.xmap
> build.xml
>
> conf/testblock.xmap inserts a match/mount into the main sitemap to mount my
> webapp/testblock/sitemap.xmap:
>
> <xmap xpath="/sitemap/pipelines/pipeline"
> unless="match[@pattern='testblock']">
> <map:match pattern="testblock/**">
> <map:mount check-reload="yes" src="testblock/" uri-prefix="testblock"/>
> </map:match>
> </xmap>
>
> I created the webapp directory to hold all the stuff I need copied to
> build/webapp, and build.xml is the ant task that copies it:
>
> <project default="main" basedir=".">
> <target name="main">
> <copy filtering="on" todir="${build.webapp}">
> <fileset dir="${block.dir}/webapp"/>
> </copy>
> </target>
> </project>
>
> Finally I added my new block to gump.xml:
>
> <project name="cocoon-block-testblock" status="unstable">
> <package>org.apache.cocoon</package>
>
> <ant target="gump-block">
> <property name="block-name" value="testblock"/>
> <property name="version" value="@@DATE@@"/>
> </ant>
>
> <depend project="cocoon" inherit="all"/>
> <work nested="tools/anttasks"/>
> <home nested="build/cocoon-@@DATE@@"/>
>
> <jar name="blocks/testblock-block.jar"/>
>
> <nag from="Gump" to="dev@cocoon.apache.org"/>
> </project>
>
> Doing a build webapp builds it and it all seems to work.
>
> Does this seem right? Is there anything else I should be doing?
>
> Also, is there a way to hot-deploy blocks without restarting jetty?
>
> cheers,
> -steve
>
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Developing a block
Posted by Steve K <sh...@myrealbox.com>.
Hey folks --
I'm starting a new Cocoon application and I want to try to take advantage of
the new 2.1 build system and the blocks stuff. As I couldn't find any
documentation on how to do this, I put together something and wanted to run
it by all of you to let me know if I'm on the right track. I added the
following directory structure to the src/blocks dir:
testblock/
conf/
testblock.xmap
java/
lib/
webapp/
testblock/
sitemap.xmap
build.xml
conf/testblock.xmap inserts a match/mount into the main sitemap to mount my
webapp/testblock/sitemap.xmap:
<xmap xpath="/sitemap/pipelines/pipeline"
unless="match[@pattern='testblock']">
<map:match pattern="testblock/**">
<map:mount check-reload="yes" src="testblock/" uri-prefix="testblock"/>
</map:match>
</xmap>
I created the webapp directory to hold all the stuff I need copied to
build/webapp, and build.xml is the ant task that copies it:
<project default="main" basedir=".">
<target name="main">
<copy filtering="on" todir="${build.webapp}">
<fileset dir="${block.dir}/webapp"/>
</copy>
</target>
</project>
Finally I added my new block to gump.xml:
<project name="cocoon-block-testblock" status="unstable">
<package>org.apache.cocoon</package>
<ant target="gump-block">
<property name="block-name" value="testblock"/>
<property name="version" value="@@DATE@@"/>
</ant>
<depend project="cocoon" inherit="all"/>
<work nested="tools/anttasks"/>
<home nested="build/cocoon-@@DATE@@"/>
<jar name="blocks/testblock-block.jar"/>
<nag from="Gump" to="dev@cocoon.apache.org"/>
</project>
Doing a build webapp builds it and it all seems to work.
Does this seem right? Is there anything else I should be doing?
Also, is there a way to hot-deploy blocks without restarting jetty?
cheers,
-steve
Re: [RT] Improving Sitemap and Flowscript
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Posted by Stefano Mazzocchi <st...@apache.org>.
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
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Improving Sitemap and Flowscript
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
>
>
>>But, if you write
>><map:generate type="filteredFile" src="something">
>>
>>then you can access it automatically as {src} rather than
>>writing
>><map:generate type="filteredFile">
>> <map:parameter name="src" value="something"/>
>>
>>
>
>We *will* regret this at some point. Don't handle @src different from
>all other parameters. IOW we should pass everything using the
>map:parameter syntax.
>
>We haven't done it with resources. We shouldn't do it here.
>
But resources don't have a "src" attribute while generators and
transformer do.
Imagine that "filteredFile" above is actually defined as "file" in the
top-level sitemap because you want to *globally* change the "file"
generator inherited by subsitemaps.
Will this require to modify all of these sitemaps because the "file"
generator is now a virtual generator ? That's not viable. This is why
virtual components must be used using the *same* syntax as normal ones.
And "src" beeing part of this syntax, this is why we need a way to pass
it to the virtual component.
Now this changes nothing for resources, which never had that "src"
attributes and won't have it because of the introduction of virtual
components.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
On Thursday, Aug 21, 2003, at 17:45 Europe/Rome, Christian Haul wrote:
> On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
>> But, if you write
>> <map:generate type="filteredFile" src="something">
>>
>> then you can access it automatically as {src} rather than
>> writing
>> <map:generate type="filteredFile">
>> <map:parameter name="src" value="something"/>
>
> We *will* regret this at some point. Don't handle @src different from
> all other parameters. IOW we should pass everything using the
> map:parameter syntax.
>
> We haven't done it with resources. We shouldn't do it here.
Good point, but to me, "src" already is a special parameter for
generators and transformers, I see no problem in making it so for
virtual ones as well.
As for resources, they were not meant to be pipeline fragments anyway,
but entire pipelines, so a special "src" attribute doesn't make any
sense for an entire pipeline.
--
Stefano.
Re: [RT] Improving Sitemap and Flowscript
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 21.Aug.2003 -- 01:40 PM, Carsten Ziegeler wrote:
> But, if you write
> <map:generate type="filteredFile" src="something">
>
> then you can access it automatically as {src} rather than
> writing
> <map:generate type="filteredFile">
> <map:parameter name="src" value="something"/>
We *will* regret this at some point. Don't handle @src different from
all other parameters. IOW we should pass everything using the
map:parameter syntax.
We haven't done it with resources. We shouldn't do it here.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [RT] Improving Sitemap and Flowscript
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>It could be convinient if it would work. But it does not.
>>
>> <map:generator name="filteredFile">
>> <map:aggregate>
>> <map:part src="a"/>
>> <map:part src="b"/>
>> <map:part src="c"/>
>> </map:aggregate>
>> <map:transform type="xslt" src="a.xsl"/>
>> <map:transform type="xslt" src="b.xsl"/>
>> </map:generator>
>>
>>
>>
>It works :)
>
>You can then:
>
><map:generate type="filteredFile">
> <map:parameter name="source-a" value="A"/>
> <map:parameter name="source-b" value="B"/>
> <map:parameter name="source-c" value="C"/>
></map:generate>
>
>with
>
>
>
>> <map:generator name="filteredFile">
>> <map:aggregate>
>> <map:part src="{source-a}"/>
>> <map:part src="{source-c}"/>
>> <map:part src="{source-b}"/>
>> </map:aggregate>
>> <map:transform type="xslt" src="a.xsl"/>
>> <map:transform type="xslt" src="b.xsl"/>
>> </map:generator>
>>
>>
>You could also add two parameters for the stylesheets etc.
>
>But, if you write
><map:generate type="filteredFile" src="something">
>
>then you can access it automatically as {src} rather than
>writing
><map:generate type="filteredFile">
> <map:parameter name="src" value="something"/>
>
With clarifications given -- no objections. I agree with this idea.
Vadim
RE: [RT] Improving Sitemap and Flowscript
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> It could be convinient if it would work. But it does not.
>
> <map:generator name="filteredFile">
> <map:aggregate>
> <map:part src="a"/>
> <map:part src="b"/>
> <map:part src="c"/>
> </map:aggregate>
> <map:transform type="xslt" src="a.xsl"/>
> <map:transform type="xslt" src="b.xsl"/>
> </map:generator>
>
It works :)
You can then:
<map:generate type="filteredFile">
<map:parameter name="source-a" value="A"/>
<map:parameter name="source-b" value="B"/>
<map:parameter name="source-c" value="C"/>
</map:generate>
with
> <map:generator name="filteredFile">
> <map:aggregate>
> <map:part src="{source-a}"/>
> <map:part src="{source-c}"/>
> <map:part src="{source-b}"/>
> </map:aggregate>
> <map:transform type="xslt" src="a.xsl"/>
> <map:transform type="xslt" src="b.xsl"/>
> </map:generator>
You could also add two parameters for the stylesheets etc.
But, if you write
<map:generate type="filteredFile" src="something">
then you can access it automatically as {src} rather than
writing
<map:generate type="filteredFile">
<map:parameter name="src" value="something"/>
Carsten
Re: [RT] Improving Sitemap and Flowscript
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>>One thing missing is passing information from the pipeline to the
>>>components.
>>>For example if you write this pipeline:
>>>
>>><map:generate type="filteredFile" src="afile.xml">
>>> <map:parameter name="a parameter" value="a value"/>
>>>...
>>>
>>>I assume that the src info and the parameters are passed to the "real"
>>>generator which in this case is the file generator. Is it
>>>
>>>
>>possible to pass
>>
>>
>>>info to the other components as well, so can I pass a parameter to the
>>>xslt transformer?
>>>I'm not sure if this is needed (or if it's FS); I have not
>>>
>>>
>>thought about it
>>
>>
>>>but it immediately came up my mind :)
>>>
>>>
>>>
>>You really have to consider virtual components as "typed resources",
>>this means we'll be able to pass parameters to these virtual components
>>just a we do today for resources.
>>
>><map:serializer type="abs-html">
>> <map:transform type="link-absolutizer">
>> <map:parametrer name="base-uri" value="{site-root}"/>
>> </map:transform>
>> <map:serialize type="html"/>
>></map:serializer>
>>
>>and then :
>><map:serialize type="abs-html">
>> <map:parameter name="site-root" value="http://my.host/root/"/>
>></map:serialize>
>>
>>
>>
>Ah, ok ,so the given example:
>
> <map:generator name="filteredFile">
> <map:generate type="file"/>
> <map:transform type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
>
>wouldn't work as the file generator would get not src, it has to:
> <map:generator name="filteredFile">
> <map:generate type="file" src="{src}"/>
> <map:transform type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
>
>with
> <map:generate type="filteredFile">
> <map:parameter name="src" value="some.xml"/>
>
>
>>The only problem is for the "src" attribute. Should we simply pass it as
>>a "src" parameter ?
>>
>>
>>
>+1, yes because then it would look like this:
>
> <map:generate type="filteredFile" src="some.xml"/>
>
How would you pass two or three src parameters?
>which is much more convenient.
>
It could be convinient if it would work. But it does not.
<map:generator name="filteredFile">
<map:aggregate>
<map:part src="a"/>
<map:part src="b"/>
<map:part src="c"/>
</map:aggregate>
<map:transform type="xslt" src="a.xsl"/>
<map:transform type="xslt" src="b.xsl"/>
</map:generator>
5 src attributes.
Vadim
Re: [RT] Improving Sitemap and Flowscript
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Aug 20, 2003, at 13:28 Europe/Rome, Carsten Ziegeler
wrote:
> Sylvain Wallez wrote:
>>> One thing missing is passing information from the pipeline to the
>>> components.
>>> For example if you write this pipeline:
>>>
>>> <map:generate type="filteredFile" src="afile.xml">
>>> <map:parameter name="a parameter" value="a value"/>
>>> ...
>>>
>>> I assume that the src info and the parameters are passed to the
>>> "real"
>>> generator which in this case is the file generator. Is it
>> possible to pass
>>> info to the other components as well, so can I pass a parameter to
>>> the
>>> xslt transformer?
>>> I'm not sure if this is needed (or if it's FS); I have not
>> thought about it
>>> but it immediately came up my mind :)
>>>
>>
>> You really have to consider virtual components as "typed resources",
>> this means we'll be able to pass parameters to these virtual
>> components
>> just a we do today for resources.
>>
>> <map:serializer type="abs-html">
>> <map:transform type="link-absolutizer">
>> <map:parametrer name="base-uri" value="{site-root}"/>
>> </map:transform>
>> <map:serialize type="html"/>
>> </map:serializer>
>>
>> and then :
>> <map:serialize type="abs-html">
>> <map:parameter name="site-root" value="http://my.host/root/"/>
>> </map:serialize>
>>
> Ah, ok ,so the given example:
>
> <map:generator name="filteredFile">
> <map:generate type="file"/>
> <map:transform type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
>
> wouldn't work as the file generator would get not src, it has to:
> <map:generator name="filteredFile">
> <map:generate type="file" src="{src}"/>
> <map:transform type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
>
> with
> <map:generate type="filteredFile">
> <map:parameter name="src" value="some.xml"/>
>>
>> The only problem is for the "src" attribute. Should we simply pass it
>> as
>> a "src" parameter ?
>>
> +1, yes because then it would look like this:
>
> <map:generate type="filteredFile" src="some.xml"/>
>
> which is much more convenient.
I like this. +1
--
Stefano.
RE: [RT] Improving Sitemap and Flowscript
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> >One thing missing is passing information from the pipeline to the
> >components.
> >For example if you write this pipeline:
> >
> ><map:generate type="filteredFile" src="afile.xml">
> > <map:parameter name="a parameter" value="a value"/>
> >...
> >
> >I assume that the src info and the parameters are passed to the "real"
> >generator which in this case is the file generator. Is it
> possible to pass
> >info to the other components as well, so can I pass a parameter to the
> >xslt transformer?
> >I'm not sure if this is needed (or if it's FS); I have not
> thought about it
> >but it immediately came up my mind :)
> >
>
> You really have to consider virtual components as "typed resources",
> this means we'll be able to pass parameters to these virtual components
> just a we do today for resources.
>
> <map:serializer type="abs-html">
> <map:transform type="link-absolutizer">
> <map:parametrer name="base-uri" value="{site-root}"/>
> </map:transform>
> <map:serialize type="html"/>
> </map:serializer>
>
> and then :
> <map:serialize type="abs-html">
> <map:parameter name="site-root" value="http://my.host/root/"/>
> </map:serialize>
>
Ah, ok ,so the given example:
<map:generator name="filteredFile">
<map:generate type="file"/>
<map:transform type="xslt" src="namespaceFilter.xsl"/>
</map:generator>
wouldn't work as the file generator would get not src, it has to:
<map:generator name="filteredFile">
<map:generate type="file" src="{src}"/>
<map:transform type="xslt" src="namespaceFilter.xsl"/>
</map:generator>
with
<map:generate type="filteredFile">
<map:parameter name="src" value="some.xml"/>
>
> The only problem is for the "src" attribute. Should we simply pass it as
> a "src" parameter ?
>
+1, yes because then it would look like this:
<map:generate type="filteredFile" src="some.xml"/>
which is much more convenient.
Carsten
Re: [RT] Improving Sitemap and Flowscript
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Stefano Mazzocchi wrote:
>
>
>> Virtual Pipeline Components
>> ---------------------------
>>
>>
>>
></SNIP>
>
>+5, the only thing I'm not sure about is the syntax in the sitemap, you
>propose:
>
>
>
>> <map:generators>
>> <map:generator name="filteredFile">
>> <map:generator type="file"/>
>> <map:transformer type="xslt" src="namespaceFilter.xsl"/>
>> </map:generator>
>>
>>
>
>because in order to work correctly you have to define the file generator
>as usual:
>
><map:generator name="file" src="SOME CLASS"/>
>
>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:
>
>
>> <map:generators>
>> <map:generator name="filteredFile">
>> <map:generate type="file"/>
>> <map:transform type="xslt" src="namespaceFilter.xsl"/>
>> </map:generator>
>>
>>
>
>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:
>
><map:generate type="filteredFile" src="afile.xml">
> <map:parameter name="a parameter" value="a value"/>
>...
>
>I assume that the src info and the parameters are passed to the "real"
>generator which in this case is the file generator. Is it possible to pass
>info to the other components as well, so can I pass a parameter to the
>xslt transformer?
>I'm not sure if this is needed (or if it's FS); I have not thought about it
>but it immediately came up my mind :)
>
You really have to consider virtual components as "typed resources",
this means we'll be able to pass parameters to these virtual components
just a we do today for resources.
<map:serializer type="abs-html">
<map:transform type="link-absolutizer">
<map:parametrer name="base-uri" value="{site-root}"/>
</map:transform>
<map:serialize type="html"/>
</map:serializer>
and then :
<map:serialize type="abs-html">
<map:parameter name="site-root" value="http://my.host/root/"/>
</map:serialize>
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
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Virtual Pipeline Components
> ---------------------------
>
</SNIP>
+5, the only thing I'm not sure about is the syntax in the sitemap, you
propose:
> <map:generators>
> <map:generator name="filteredFile">
> <map:generator type="file"/>
> <map:transformer type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
because in order to work correctly you have to define the file generator
as usual:
<map:generator name="file" src="SOME CLASS"/>
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:
> <map:generators>
> <map:generator name="filteredFile">
> <map:generate type="file"/>
> <map:transform type="xslt" src="namespaceFilter.xsl"/>
> </map:generator>
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:
<map:generate type="filteredFile" src="afile.xml">
<map:parameter name="a parameter" value="a value"/>
...
I assume that the src info and the parameters are passed to the "real"
generator which in this case is the file generator. Is it possible to pass
info to the other components as well, so can I pass a parameter to the
xslt transformer?
I'm not sure if this is needed (or if it's FS); I have not thought about it
but it
immediately came up my mind :)
Carsten