Re: [C3] redirect-to/@uri optional?
Reinhard Pötz pisze: Grzegorz Kossakowski wrote: Hi, It's again me trying to understand current sitemap design. This time I wonder if it's intended that redirect-to/@uri is optional. I fail to see how implementation of redirect-to handles this case in any meaningful way. I haven't tried it now what happens if the there is no @uri attribute but from reading the code some exception in the RedirectorComponent will occur. It's probably better to throw a meaningful exception in the RedirectorNode. So do you agree with me changing both schema and implementation so @uri is required? The same concern (about too many of optional attributes) applies to call instruction. What about this? BTW. Was the idea of having extensible sitemap syntax discussed earlier? As it something new I wonder what was the main idea behind such a design decision. Why do you think that this is new? When Sylvain wrote the TreeProcessor, one of his main goals was extensibility. Right. I wasn't active committer at that time so I can't remember original goals of TreeProcessor. Anyway, I wonder if this functionality was ever used in 2.x? I can't recall such a situation. If I understand it correctly having extensible sitemap language adds quite a lot to complexity of sitemap implementation. I would like to know what kind of issues extensibility of sitemap language solves. -- Best regards, Grzegorz Kossakowski
Re: Very early 2.1.12-dojo1_1-dev committed
Hi Roy Many thanks for the continued updates. Sorry to say, still too busy earning at the moment regards Jeremy On 16 Feb 2009, at 04:40, lingerer huang wrote: Hi,Jeremy The new dojo 1.3 is on the way. When I tried using dojo 1.3 beta1,many widgets failed. According to the http://trac.dojotoolkit.org/ticket/7994 , the implement should modified too. Regards Roy Huang.
Re: [c3] osginize jars
On Sunday 22 February 2009 19:10:34 Reinhard Pötz wrote: Andreas Pieber wrote: Hi, I'm in the situation that I require the cocoon-pipeline-artefacts in a standalone eclipse RCP-application. I like to use the cocoon XML pipeline directly from my code to write parts of HUGE XML files directly into the database (as domain-objects). I osginized the bundles by using the felix- bundle-plugin. I think we could safely osginize all cocoon3 artefacts in that way. Your example patch relies on the automatic generation of import and export manifest properties. I guess this is intentional but are all these properties correct? Yes they are correct, and I wouldn't be able to make them better :) At the company I'm working at we converted some dozen of jars to bundles in this way and never had any problems, but I think I've read that there's an option to fire up an Apache-Felix-Engine and run the integration/unit tests there to make sure that no issues are introduced. There could be some issues with AOP in an OSGi environment and it may also be nice to provide some sitemap services as OSGi services. But IMHO this could be done in another iteration since the pipeline-API (including cocoon-sax and cocoon-stax) work very well without considering these (possible) issues. Yes, managing servlet-services with OSGi is a different problem. Daniel, who is the main author of the servlet-service framework, designed it in a way that the introduction of OSGi shouldn't be too difficult. But I'm sure that there are still a lot of problems to be solved, especially OSGi and AOP as you've already mentioned. I hope I find some time to dig deeper here too, although it's not required for me at the moment. On positive feedback I'll open a feature request and provide a patch osginizing all cocoon3 artifacts. So WDYT? Go ahead - your work is highly appreciated! I'm happy about that and hope to be able to provide a first applyable patch till the end of the week. Andreas
Re: [C3] redirect-to/@uri optional?
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
Grzegorz Kossakowski wrote:
Hi,
It's again me trying to understand current sitemap design. This time
I wonder if it's intended that redirect-to/@uri is optional. I fail
to see how implementation of redirect-to handles this case in any
meaningful way.
I haven't tried it now what happens if the there is no @uri attribute
but from reading the code some exception in the RedirectorComponent will
occur. It's probably better to throw a meaningful exception in the
RedirectorNode.
So do you agree with me changing both schema and implementation so @uri is
required?
yes, go ahead
llnode
The same concern (about too many of optional attributes) applies to
call instruction.
What about this?
@controller and @select could be mandatory. Once I was thinking about
having a default controller for a sitemap (e.g. defined at the root
element) but have never implemented it. It that case @controller would
have to become optional.
BTW. Was the idea of having extensible sitemap syntax discussed
earlier? As it something new I wonder what was the main idea behind
such a design decision.
Why do you think that this is new? When Sylvain wrote the TreeProcessor,
one of his main goals was extensibility.
Right. I wasn't active committer at that time so I can't remember original
goals of TreeProcessor. Anyway, I wonder if
this functionality was ever used in 2.x? I can't recall such a situation.
If I understand it correctly having extensible sitemap language adds quite a
lot to complexity of sitemap
implementation. I would like to know what kind of issues extensibility of
sitemap language solves.
There was the idea of designing page flows in XML (very similar to
Spring MVC) but this idea was dropped in favor of Flowscript. You can
guess now how old this idea has to be ;-)
Nowadays I don't know of any use case but when we implemented
cocoon-sitemap we thought that we should make it extensible, especially
because the sitemap module can be used stand-alone very easily.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
[continuum] BUILD SUCCESSFUL: Cocoon - Apache Cocoon [build root] -
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=148368projectId=51 Build statistics: State: Ok Previous State: Error Started at: Tue 24 Feb 2009 13:04:16 -0800 Finished at: Tue 24 Feb 2009 13:17:46 -0800 Total time: 13m 30s Build Trigger: Schedule Build Number: 357 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.9 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 Family: unix SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -P allblocks,it Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Maven 2.0.9, Java 5, Large Memory Description: Test Summary: Tests: 372 Failures: 0 Total time: 95.80398
