Re: [VOTE] Alfred Nathaniel as committer
Bertrand Delacretaz wrote: Please cast your votes: +1 --David
Re: Manually specifying a mounted sub sitemap's context
On Apr 10, 2005 4:24 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: So, although we may accept a new context attribute (I'm currently -0.9 for this), I'm -1 for accepting dynamically generated sitemaps. I'm -1 as well. (that was easy to guess ;-) Uhm, first of all I'd say that the context attribute could be really useful in contexts other than dynamic sitemaps, so I'd welcome that addition. WRT dynamic sitemaps, I don't quite have a real opinion, I can clearly see how it might lead to abuse, but I also tend to think that Cocoon, as a framework, should allow applications built on top of it using subsets of functionalities abstracted in high level configuration files. However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Manually specifying a mounted sub sitemap's context
Gianugo Rabellino wrote: useful in contexts other than dynamic sitemaps, so I'd welcome that addition. WRT dynamic sitemaps, I don't quite have a real opinion, I can clearly see how it might lead to abuse, but I also tend to think that Cocoon, as a framework, should allow applications built on top of it using subsets of functionalities abstracted in high level configuration files. However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Ciao, I guess I have mixed feelings about this. On the one hand, allowing dynamic sitemaps could be a huge security risk. On the other hand, we are doing something quite similar with the portal today. The portal requires 4 configuration files, one of which is the portal layout. The portal layout defines what pipelines to invoke for specific portlets and which portlets are available and on what page they appear. We dynamically generate this based upon attributes of the client and it is one of the key features that will drive us to use Cocoon as the basis for all our future applications. While this is not quite the same as having a dynamic sitemap, I could easily see someone using the same technique on the sitemaps if they weren't using the portal.
Re: Manually specifying a mounted sub sitemap's context
Le 10 avr. 05, à 17:54, Gianugo Rabellino a écrit : ...A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). And making it a configurable switch with a big warning on it would allow people to use dynamic sitemaps at their own risk, while making it clear that it's usually a bad idea. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Manually specifying a mounted sub sitemap's context
Antonio Gallardo wrote: On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo: Sylvain Wallez [EMAIL PROTECTED] wrote on 09.04.2005 20:51:41: In other words, should it be: map:mount src=foo/bar/ context=baz/ and map:sitemap or map:mount src=foo/bar// and map:sitemap context=baz/ My feeling favors the second form, as allowing to specify the context externally means that understanding what a sitemap does depends on the mount statement. Agreed, the second form is easier to understand. The first one was just easier to implement (at least for me), since MountNode.invoke already resolves the sitemap context. And this was the point where cocoon went into endless recursion... On the other hand, the first form offers one additional feature: Mounting the same sitemap twice with different contexts. I just don't know yet if this is a good idea... I see this as a good idea. I have a lot of literally equals sitemaps that with something like that I can get rid of them by just defining his context. What do you mean by literally equals? Do they differ because: - there is a a slight difference in what they should do (in that case what about pass-through mounts?) - or because they provide the same pipelines but operate on different data? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Manually specifying a mounted sub sitemap's context
Gianugo Rabellino wrote: On Apr 10, 2005 4:24 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: So, although we may accept a new context attribute (I'm currently -0.9 for this), I'm -1 for accepting dynamically generated sitemaps. I'm -1 as well. (that was easy to guess ;-) Uhm, first of all I'd say that the context attribute could be really useful in contexts other than dynamic sitemaps, so I'd welcome that addition. WRT dynamic sitemaps, I don't quite have a real opinion, I can clearly see how it might lead to abuse, but I also tend to think that Cocoon, as a framework, should allow applications built on top of it using subsets of functionalities abstracted in high level configuration files. However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Well, as long as there is the http route, blocking cocoon: will just lead people to use an uglier workaround which you just engraved in the archives for posterity ;-) So if we're to enforce something, it should be that a sitemap is a file, or a classpath resource (yes, I have this usecase). Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
[Ann/RFC] Virtual Sitemap Components
I have continued Vadim's and Sylvain's work and added a first, hopefully
working version of virtual sitemap components (VPCs) to the trunk.
Use
===
To use VPCs one define them in the components section in the sitemap, e.g.:
map:components
map:readers
map:reader name=virtual1
src=org.apache.cocoon.reading.VirtualPipelineReader
map:generate type=file src=vpc-test.xml/
map:serialize type=xml/
/map:reader
/map:readers
map:transformers default=xslt
map:transformer name=virtual2
src=org.apache.cocoon.transformation.VirtualPipelineTransformer
map:source param=src2/
map:transform src=vpc-include.xsl
map:parameter name=file value={src}/
/map:transform
map:transform src=vpc-include.xsl
map:parameter name=file value={src2}/
/map:transform
/map:transformer
/map:transformers
/map:components
then they can be used as any component:
map:read type=virtual1/
map:transform type=virtual2 src=vpc-test.xml
map:parameter name=src2 value=vpc-test2.xml/
/map:transform
in the sitemap where they are defined and in all its subsitemaps.
One of the complicated things with VPCs was how and where to resolve
sources that are given to VPCs. I followed Sylvain's aproach in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110064557022481w=2
modified with my ideas
(http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110539791029866w=2)
about how to increase the level of isolation between the caller and the
callee. This will be needed when we use them from real blocks.
To use a source as a parameter one have to declare it with
map:source param=src2/
in the definition. The src is always supposed to be a source. Sources
are alwas resolved in the calling sitemap.
--- o0o ---
More examples of use can be found in the sitemaps for the test cases in
src/test/org/apache/cocoon/[generation|transformation|serialization|reading].
I didn't research old mails about VPCs about what things are supposed to
be called. So suggestions about better names and syntax are welcome.
VPCs are not cacheable yet. Its probably not that hard to add caching,
but it requires that we extend the ProcessingPipeline interface with
some methods that are needed for VPCs. It also requires that we find
some syntax for declaring what pipeline type that should be used for a
specific VPC.
Implementation
==
In the rest of the mail I will give an overview of the implementation.
The VPCs is rather complicated, so I would appriciate if people could
spend some thought and testing on them so we can be sure that they are
correct.
TreeProcessor
-
In the TreeProcessor the VPCs are handled by: ComponentsNodeBuilder,
VPCsNodeBuilder, VPCNodeBuilder, VPCNode and some definitions in
sitemap-language.xml.
In the TreeProcessor the VPC definitions are recognized in the
components section in the sitemap, the source parameters are parsed and
a partial pipeline node is constructed and put in the Avalon context so
that it can be found by sitemap components during setup (see Sylvain's
mail for details).
VPCs
All sitemap components have
o.a.c.sitemap.impl.AbstractVirtualSitemapComponent as base class. Its
main tasks are to find and setup its partial pipeline from the Avalon
context and taking care of parameters. It also extends AbstractXMLPipe
which only is used for the transformer and serializer, but I didn't feel
like creating several versions (its a fun exercise for one of those who
think that single inheritance is a feature rather than a nuisance ;) ).
The parameters that are declared as sources are resolved in the
environment of the calling sitemap the they are put in a map in the
environment that the VPC pipeline will be executed in (which is based on
the pipeline where it was defined). The source URI in the caller is
substituted with an xmodule or module URI that fetches the resolved
source from the environment (more details can be found in my post cited
above).
The AbstractVirtualSitemapComponent also sets up two environments,
mappedSourceEnvironment that is an extension of the callers environment
with the map with resolved sources and vpcEnvironment which is an
extension of the previous environment with context URI and prefix from
the sitemap where the VPC is defined.
The vpcEnvironment is used during creation of the partial pipeline from
the pipeline node and during preparation of the pipeline. The
mappedSourceEnvironment is used during execution of the pipeline.
Environment
---
One of the main tasks in the respective VPCs: VirtualPipelineGenerator,
VirtualPipelineTransformer, VirtualPipelineSerializer and
VirtualPipelineReader, is to execute things in the right environment. To
achieve this I have added methods to the internal class
EnvironmentHelper for entering and leaving an environment and also two
XMLConsumer adapters PushEnvironmentChanger and
Re: Manually specifying a mounted sub sitemap's context
On Apr 10, 2005 10:17 PM, Sylvain Wallez [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: However, if it's agreed once and for all that dynamic sitemaps are to be considered harmful, so be it and let's enforce it: it slipped through already, and now it doesn't work anymore because of a bug. A check failing with an error message would be enough to prevent stupid people like me to try it again in the future (even though there will always be the http route...). Well, as long as there is the http route, blocking cocoon: will just lead people to use an uglier workaround which you just engraved in the archives for posterity ;-) Hey, I wasn't the first one to suggest that ;-) So if we're to enforce something, it should be that a sitemap is a file, or a classpath resource (yes, I have this usecase). Yep. Tricky, though: I sure can imagine sitemaps stored anywhere (why not a JSR170 repo? or a webdav server? as long as it's static stuff...), and blocking this possibility just to avoid (ab)use of possibly dynamic protocols such as cocoon or http could be a bit too much. I'd rather go for a big fat warning then... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
DO NOT REPLY [Bug 34392] New: - eclipse-project target not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34392 Summary: eclipse-project target not working Product: Cocoon 2 Version: 2.1.7 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P1 Component: core AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] The eclipse-project target is not working properly. If I download cocoon, unpack it in the workspace and then create the .project with the given ant target, i cannot import/restore the project inside eclipse. This is caused by the bug 76417 ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=76417 ) in eclipse, simply the project name must match the folder name. It could seem a stupid problem, but reconfiguring the cocoon eclipse project by hand is something really frustrating and time consuming, and the eclipse error message is confusing and unclear. I suggest that the generated .project file uses the directory name as project name, instead of Cocoon 2.1.7. A dirname ant task could solve the problem, I'll check it out. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 34392] - eclipse-project target not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34392. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34392 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P1 |P5 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: Manually specifying a mounted sub sitemap's context
On Dom, 10 de Abril de 2005, 15:12, Sylvain Wallez dijo: Antonio Gallardo wrote: On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo: Sylvain Wallez [EMAIL PROTECTED] wrote on 09.04.2005 20:51:41: In other words, should it be: map:mount src=foo/bar/ context=baz/ and map:sitemap or map:mount src=foo/bar// and map:sitemap context=baz/ My feeling favors the second form, as allowing to specify the context externally means that understanding what a sitemap does depends on the mount statement. Agreed, the second form is easier to understand. The first one was just easier to implement (at least for me), since MountNode.invoke already resolves the sitemap context. And this was the point where cocoon went into endless recursion... On the other hand, the first form offers one additional feature: Mounting the same sitemap twice with different contexts. I just don't know yet if this is a good idea... I see this as a good idea. I have a lot of literally equals sitemaps that with something like that I can get rid of them by just defining his context. What do you mean by literally equals? Do they differ because: - there is a a slight difference in what they should do (in that case what about pass-through mounts?) - or because they provide the same pipelines but operate on different data? The second: they provide the same pipelines but operate on different data. Building webapps, you have some forms sets (businnes module? [BM]) that provide basic functionality (create, edit, search) on diferent data (tables). Perhaps this is our fault, I know I can use a parent sitemap for that. But we don't see it as a good solution for us, since we want to keep every BM separated (and independent) of the others. That can allow us to move a defined MB to another application by just copy paste a MB. Maybe we need to find another solution for that. Best Regards, Antonio Gallardo.
