Hunsberger, Peter wrote:
Now-a-days I think anyone that has done even a bit of Web programming
has been exposed to some form of Object Model. Microsoft refers to them
in their DHTML documentation, then you've got all the various DOMs
hanging around.
Microsoft isn't actually my official
Gianugo Rabellino [EMAIL PROTECTED] writes:
Hunsberger, Peter wrote:
Now-a-days I think anyone that has done even a bit of Web
programming
has been exposed to some form of Object Model. Microsoft refers to
them in their DHTML documentation, then you've got all the various
DOMs
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
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
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:
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
From: Christian Haul
I'll think about more juicy use cases tonight.
Great!
... and here some thoughts from an AOP beginner ;)
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106153567628087w=2
Reinhard
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
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
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
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
]
- Original Message -
From: Stefano Mazzocchi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, August 23, 2003 8:51 AM
Subject: Re: [RT] Improving Sitemap and Flowscript
...
Ok, here is what I think it would be wise to do:
1) leave cocoon.xconf as is
2) allow the sitemap to get
From: Christian Haul [mailto:[EMAIL PROTECTED]
Interception in Flowscript
Something that can be modelled very well as an aspect is
authentication/authorization (aka login) because it's not
something that
is part of the webapp (at least, it shouldn't
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
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
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
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
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
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
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,
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();
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
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
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
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*
-mail; this happened
on the users list, though, not sure if you saw it).
Sincerely,
Jay Freeman (saurik)
[EMAIL PROTECTED]
- Original Message -
From: Stefano Mazzocchi [EMAIL PROTECTED]
To: Apache Cocoon [EMAIL PROTECTED]
Sent: Friday, August 15, 2003 5:11 PM
Subject: [RT] Improving Sitemap
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
note
I resend again this post, since I dont got it in my mailbox. It seems like
the 2 virus in the wild (Sobig.f and MSBlast) are causing major troubles
in the Internet...
Please stop using the major virus called Windows ;-D
/note
So, after making a request for this a few days ago, with some
PROTECTED]
Sent: Wednesday, August 20, 2003 5:57 AM
Subject: Re: [RT] Improving Sitemap and Flowscript
...
I think it could not be a big change if we separate the current
sitemap.xmap in:
WEB-INF/components.xconf- map:components part of current
sitemap.xmap sitemap.xmap
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
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
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.
47 matches
Mail list logo
