Re: Use of the what command with java code (was: Including source files in jars)
Le 9 juin 04, à 07:54, Antonio Gallardo a écrit : ...What about the other proposal I did: Insert in META-INF/MANIFEST.MF file the SVN Revision number (+ maybe other needed stuff - need to investigate) of the local working copy at compile time? (BTW, It does not requiere net access, because the info is retrieved from your local working copy)... I think you're right, with SVN this is enough as the revision number applies to the whole source tree, no need for individual file revision info. It won't solve Tim's problem of using non-committed code, but it's a lightweight and elegant way of knowing from which (checked-in) version your code was built. I never used ant tasks to get at SVN info but someone has probably done it already. -Bertrand
RE: [RT] Logging and log4j
Antonio Gallardo wrote: Hi Carsten: Third time I will write the same here. Not your fault. :) I don't like the idea to switch to log4j as the default implementation. I was researching how to set in log4j the file paths to WEB-INF/logs for any servlet and I don't found a right answer. There were worksrounds, but no an elegant solution as in LogKit. Ah, that's right. I was looking at that some time ago as well and didn't find it. Ok, we can research this. I found this interesting mail in log4j. The explanation is that LogKit is more oriented to IoC usage (Avalon). Quoting [1]: quote The only real difference I see is the philosophical one of how Loggers should be obtained. LogKit was designed for use in frameworks where the principle of inversion of control is extensively applied. One implication of IoC is that components are passive, and interact with the outside world solely through their container. There is a well-defined component lifecycle. In Avalon, the first thing that happens to a component is that it is *given* a Logger. It doesn't request one through a static method like Logger.getLogger(..), since that would break IoC and potentially cause a security risk (overhead-less security is one of IoC's benefits). /quote I know the mail is already 3 years old. Can someone explain if this is diferent now? No, ..eh...yes. If you're using log4j the way log4j tells you to do, this is still the same ugly way of getting a logger. But, with Cocoon (or with Avalon components) it's still IoC. Your component gets a logger which might be a log4j logger (or anything else). My main concern is that in log4j you need to write an absolut path for the log file. For me this is a step back on what we have now. I really love the idea to move the servlets to any location and not need to configure log file paths. Yes, I agree that writing absolute paths is really bad. (I wouldn't put the logs into WEB-INF/logs for production systems, but that's another story). I will be glad if someone can explain or write a doc telling that I am wrong. I really wanted to use log4j, but not at any cost. Second concern on the list is performance. Already discused, but without a probe. I think my suggestion covers this issue very well; there isn't any dfference in performance then anymore. I prefer to have (as now) LogKit as the default logger. Ok, accepted. So if we could solve the problem with the absolute paths and the performance, I assume that you are not against it, right? :) Thanks Carsten
RE: [RT] Cocoon component container and excalibur
Antonio Gallardo wrote: Can I jump there? I am waiting to the Excalibur TLP setup to go there. I will be glad to help there too. Great news! It's a usual Apache open source project, so everyone can be part of it. It will take some more days until the project is setup :( Carsten
RE: [RT] Cocoon component container and excalibur
Carsten Ziegeler dijo: Antonio Gallardo wrote: Can I jump there? I am waiting to the Excalibur TLP setup to go there. I will be glad to help there too. Great news! It's a usual Apache open source project, so everyone can be part of it. I mean, committer right. Is this posible? AFAIK, currently, each Cocoon committer has this rights: avalon-components avalon-excalibur avalon-sandbox I never used it, but I will be glad to start using them. It will take some more days until the project is setup :( No problem. I can wait for it :-D Best Regards, Antonio Gallardo
Re: Groovy, Flow Page Templates
Le 8 juin 04, à 21:16, Tony Collen a écrit :
... map:generate type=script src={1}.gy/
...
sendPageAndWait(confirm_register.gsp, {bizdata : bizdata});
...
How would one go about getting:
a) The bizdata object
b) The continuation id
I guess the question is where does sendPageAndWait store bizdata, but
I don't know ;-)
If it's request attributes, you'll be able to get at them from Groovy
through the objectModel and then the request object. And the
ScriptableGenerator can be easily ehanced to make more stuff available
directly to Groovy scripts.
Note that, last time I checked, the execution of Groovy-based pages was
*very* slow, like down to 2 pages per second only. It might not be a
Groovy problem, but rather our naive implementation which probably
initializes a lot of stuff and interprets the Groovy script every time.
There are better ways to embed Groovy than BSF tough [1], so it might
be worth writing something better in someone's Copious Free Time...
-Bertrand
[1] http://groovy.codehaus.org/Embedding+Groovy
Re: Groovy, Flow Page Templates
Bertrand Delacretaz wrote:
Le 8 juin 04, 21:16, Tony Collen a crit :
... map:generate type=script src={1}.gy/
...
sendPageAndWait(confirm_register.gsp, {bizdata : bizdata});
...
How would one go about getting:
a) The bizdata object
b) The continuation id
I guess the question is where does sendPageAndWait store bizdata, but
I don't know ;-)
in ObjectModel, see o.a.c.components.flow.FlowHelper
--
Leszek Gawron [EMAIL PROTECTED]
Re: [cforms] Simple XML binding
Andreas Hochsteger wrote: Hi Daniel, this sounds really interesting! Would this functionality allow you to bind XML content to a textarea input element too? What I mean is, that this way you could populate certain parts of an XML document directly with the XHTML-Output of the HTMLArea control (or plain textarea if you like). Thanks, Andreas. There is no such functionality this far, but it sound like a useful extension. I think it would be best to implement it by creating an XML data type for CForms. The XML data type is reponsible for converting between text (in the input element e.g.) and an appropriate Java data type, (DOM i guess). The XMLAdapter could then be extended so that it can recognize the XML data type, and populate and serialize it. WDYT? /Daniel
Re: Including source files in jars
Ralph Goers wrote:
I guess I'm missing something. I thought the point was to have the source for
dependent projects that are snapshots in the jars. That makes sense to me. In that
case I'm not sure how having a build property helps since the source would need to be
in the jar that is part of the Cocoon download.
If this discussion is about putting Cocoon source in jars, I'm not sure what the point of that is since you have to download the source to build.
Ok, I think not to have explained the use case clearly. It is actually
very close to what you explain about dependent projects. This feature is
not useful for us Cocoon devs, but for project developpers that use
unreleased versions.
We have a project here in my company with complex recursive forms which
required me to extend CForms. I do not work directly on the project, but
provide its developpers with new versions of forms-block.jar that run
with the official 2.1.5. The purpose of including the sources in jar
files is for the developpers of this project to be able to know with no
ambiguity what sources they use. Furthermore when these sources are not
yet in Cocoon's CVS (don't worry, commits will come soon).
These guys are in the office next to mine, so roundtrip time is fast and
communication easy. Now consider a project made for a remote customer,
which required to use a non-released version because of a bug to fix or
a few feature to implement. One year after the project is finished, the
customer calls back because some errors occur. How do you know what
sources the project actually uses? Just ask the customer to send you the
contents of WEB-INF/lib!
So, to restate it, this feature is of little use for us Cocoon devs but
very useful for users of CVS snapshots. It's just useful for them as it
would be useful for us to have source of snapshots of dependent projects
in the corresponding jars.
Does it make more sense?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Logging and log4j
Carsten Ziegeler dijo: Ok, accepted. So if we could solve the problem with the absolute paths and the performance, I assume that you are not against it, right? :) Yep. A big +1 :-D Best Regards, Antonio Gallardo
Re: Use of the what command with java code
Bertrand Delacretaz wrote:
Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
...What about the other proposal I did:
Insert in META-INF/MANIFEST.MF file the SVN Revision number (+ maybe
other needed stuff - need to investigate) of the local working copy at
compile time? (BTW, It does not requiere net access, because the info is
retrieved from your local working copy)...
I think you're right, with SVN this is enough as the revision number
applies to the whole source tree, no need for individual file revision
info.
What if you have a partial update, e.g. keep the officially released
core, but use a snapshot of a periperal function or blocks?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Including source files in jars
Joerg Heinicke wrote:
On 08.06.2004 23:47, Sylvain Wallez wrote:
Not really convinced, but I can live with it. And now that you are
the PMC chair ... :-P
Hey, being the chair gives me no particular decision power!
Of course not - therefore the smiley. Did I ever gave the impression
that I accept opinions just because somebody else has a title ;-)
:-)
Ok, I am reassured!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Le 9 juin 04, à 09:55, Sylvain Wallez a écrit : Bertrand Delacretaz wrote: Le 9 juin 04, à 07:54, Antonio Gallardo a écrit : ...What about the other proposal I did: Insert in META-INF/MANIFEST.MF file the SVN Revision number (+ maybe other needed stuff - need to investigate) of the local working copy at compile time? (BTW, It does not requiere net access, because the info is retrieved from your local working copy)... I think you're right, with SVN this is enough as the revision number applies to the whole source tree, no need for individual file revision info. What if you have a partial update, e.g. keep the officially released core, but use a snapshot of a periperal function or blocks? Hmmm...yes, that's clearly a use-case for individual file revision info. Another case would be when you have your own source code control system for parts of Cocoon that you (temporarily) maintain yourself, like what you currently do with your forms stuff. Note that I have nothing against your including of source files in jars as a switchable option - you're right that this is the more precise info that we can provide. My conclusion would be that including the SVN revision number as proposed by Antonio is good for the common case, and your include source in jars switch can be used for extreme/uncommon cases - so why not have both? -Bertrand
Re: [cforms] Simple XML binding
Bruno Dumon wrote: On Tue, 2004-06-08 at 18:11, Daniel Fagerstrom wrote: I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter between a form object and a simple XML format that can be used without needing to wriite a binding definition. snip/ WDYT? Very useful addition. I've been thinking about such a thing myself, but never got to it. This effectively provides zero-effort load/store of the form content. Thanks! Thanks, I have a question about locale handling in cforms that maybe you (or someone else) could answer. In the conversion between the text in XML and the widgets I use the locale that is set globaly within the form. Does this mean that the XML format will depend on what locale the client has? In such case, that is not what I want to achieve, I think that the XML format should be locale independent (at least as default), how do one implement that? /Daniel
Re: Use of the what command with java code
Bertrand Delacretaz dijo: Le 9 juin 04, à 09:55, Sylvain Wallez a écrit : Bertrand Delacretaz wrote: What if you have a partial update, e.g. keep the officially released core, but use a snapshot of a periperal function or blocks? Hmmm...yes, that's clearly a use-case for individual file revision info. Another case would be when you have your own source code control system for parts of Cocoon that you (temporarily) maintain yourself, like what you currently do with your forms stuff. Note that I have nothing against your including of source files in jars as a switchable option - you're right that this is the more precise info that we can provide. My conclusion would be that including the SVN revision number as proposed by Antonio is good for the common case, and your include source in jars switch can be used for extreme/uncommon cases - so why not have both? Sylvain: Please, note I already agreed with your proposal. I understand it is convenient at special cases. I am just against to make them a default. About the SVN Revision Number, I think is convenient too and it will be enough for snapshot users. But, I am not sure if it can be on as default. WDYT? Best Regards, Antonio Gallardo. Best Regards, Antonio Gallardo.
Re: Use of the what command with java code
Bertrand Delacretaz wrote:
Le 9 juin 04, à 09:55, Sylvain Wallez a écrit :
Bertrand Delacretaz wrote:
Le 9 juin 04, à 07:54, Antonio Gallardo a écrit :
...What about the other proposal I did:
Insert in META-INF/MANIFEST.MF file the SVN Revision number (+ maybe
other needed stuff - need to investigate) of the local working copy at
compile time? (BTW, It does not requiere net access, because the
info is
retrieved from your local working copy)...
I think you're right, with SVN this is enough as the revision number
applies to the whole source tree, no need for individual file
revision info.
What if you have a partial update, e.g. keep the officially released
core, but use a snapshot of a periperal function or blocks?
Hmmm...yes, that's clearly a use-case for individual file revision
info. Another case would be when you have your own source code control
system for parts of Cocoon that you (temporarily) maintain yourself,
like what you currently do with your forms stuff.
Note that I have nothing against your including of source files in
jars as a switchable option - you're right that this is the more
precise info that we can provide.
My conclusion would be that including the SVN revision number as
proposed by Antonio is good for the common case, and your include
source in jars switch can be used for extreme/uncommon cases - so why
not have both?
There's a problem with Antonio's proposal: people that download the
official release don't have the source control information (be it CVS or
SVN), yet still have to build their own copy of Cocoon.
So I'm more in favor of including the what information, which puts a
small but indelibile stamp in class files (provided of course that the
file hasn't been modified after its checkout).
And yes, I admit that my solution is good only for uncommon cases, i.e.
for hard-core users living on the bleeding edge :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Le 9 juin 04, à 11:24, Sylvain Wallez a écrit : ...There's a problem with Antonio's proposal: people that download the official release don't have the source control information (be it CVS or SVN), yet still have to build their own copy of Cocoon... Not sure if I understand: the SVN release number would be included in the manifest in jar files, and people can use cvsview (or whatever the SVN equivalent is) to get at the right version of the file, isn't it? ...So I'm more in favor of including the what information, which puts a small but indelibile stamp in class files (provided of course that the file hasn't been modified after its checkout) And this could work for your own code as well if you respect the what convention, so I agree that it is more precise. The downside is making sure this info is in every source file, we'd need a script or ant task to check I guess. ...And yes, I admit that my solution is good only for uncommon cases, i.e. for hard-core users living on the bleeding edge :-) hehe ;-) -Bertrand
Re: [cforms] Simple XML binding
On Wed, 2004-06-09 at 10:36, Daniel Fagerstrom wrote: Bruno Dumon wrote: On Tue, 2004-06-08 at 18:11, Daniel Fagerstrom wrote: I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter between a form object and a simple XML format that can be used without needing to wriite a binding definition. snip/ WDYT? Very useful addition. I've been thinking about such a thing myself, but never got to it. This effectively provides zero-effort load/store of the form content. Thanks! Thanks, I have a question about locale handling in cforms that maybe you (or someone else) could answer. In the conversion between the text in XML and the widgets I use the locale that is set globaly within the form. Does this mean that the XML format will depend on what locale the client has? yes In such case, that is not what I want to achieve, I think that the XML format should be locale independent (at least as default), I think so too how do one implement that? simply use Locale.US? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [cforms] Simple XML binding
Daniel Fagerstrom wrote: Andreas Hochsteger wrote: Hi Daniel, this sounds really interesting! Would this functionality allow you to bind XML content to a textarea input element too? What I mean is, that this way you could populate certain parts of an XML document directly with the XHTML-Output of the HTMLArea control (or plain textarea if you like). Thanks, Andreas. There is no such functionality this far, but it sound like a useful extension. I think it would be best to implement it by creating an XML data type for CForms. The XML data type is reponsible for converting between text (in the input element e.g.) and an appropriate Java data type, (DOM i guess). The XMLAdapter could then be extended so that it can recognize the XML data type, and populate and serialize it. WDYT? Yes, I thought about an XML data type for CForms too some time ago (http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107644540003885w=2). Unfortunately I didn't find the time to take a closer look at it. Your solution sounds good to me. /Daniel Andreas.
Re: Use of the what command with java code
Le 9 juin 04, à 11:51, Sylvain Wallez a écrit : .../me kindly reminds Bertrand that Cocoon is released as source only :-) /me goes back in his corner, ears pointing down ;-) In the distro, there's no SVN or CVS directories from where we could get the version info. So how do we get this info included in the jars with an official distro? Of course, sorry for not waking up more today ;-) Which means you were 100% right that what info is better than jar manifest info as long as we're not shipping jars. This is not urgent but it would be useful, shall I create a bugzilla task so that we don't forget? -Bertrand
Re: Use of the what command with java code
Bertrand Delacretaz wrote: Le 9 juin 04, à 11:24, Sylvain Wallez a écrit : ...There's a problem with Antonio's proposal: people that download the official release don't have the source control information (be it CVS or SVN), yet still have to build their own copy of Cocoon... Not sure if I understand: the SVN release number would be included in the manifest in jar files, and people can use cvsview (or whatever the SVN equivalent is) to get at the right version of the file, isn't it? Even better would be to have directly the URL that would return you the source file. SVN is already web based, you don't need viewcvs or anything else, just the right URL (do a tcpflow dump of the SVN client over http and you know what I mean) -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Use of the what command with java code
Bertrand Delacretaz wrote:
Le 9 juin 04, à 11:51, Sylvain Wallez a écrit :
.../me kindly reminds Bertrand that Cocoon is released as source only
:-)
/me goes back in his corner, ears pointing down ;-)
;-P
In the distro, there's no SVN or CVS directories from where we could
get the version info. So how do we get this info included in the jars
with an official distro?
Of course, sorry for not waking up more today ;-)
Which means you were 100% right that what info is better than jar
manifest info as long as we're not shipping jars. This is not urgent
but it would be useful, shall I create a bugzilla task so that we
don't forget?
+1 !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Use of the what command with java code
Stefano Mazzocchi wrote:
Even better would be to have directly the URL that would return you
the source file. SVN is already web based, you don't need viewcvs or
anything else, just the right URL (do a tcpflow dump of the SVN client
over http and you know what I mean)
Hey, cool idea! We could even have the what result be formatted as
HTML linking to source files!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: TestCronJob
On 8 Jun 2004, at 08:20, Paul Russell wrote: On 7 Jun 2004, at 19:37, Jeremy Quinn wrote: On 7 Jun 2004, at 18:18, Paul Russell wrote: Reading Jeremy's mail, it sounds like this is part test, and part 'BasicCronJob'. Can I suggest that we split the two things apart? Create a BasicCronJob which is configurable to call an arbitrary pipeline, and optionally log the results, and a separate TestCronJob which is there specifically for testing? I have a working one. I called it CocoonPipelineCronJob, it is configured from cocoon.xconf with one parameter pipeline, this is then called as a 'cocoon://' pipeline. If the logging level is set to 'info' for 'cron', the output of the pipeline is written to the cron log. I use it for sending emails, but it could be used for other stuff like updating indexes etc. I suppose it could be generalised by allowing it to access any source, not just cocoon:// pipelines. It could be embellished by adding an option to allow it to output the called pipeline to a WriteableSource. Sounds good! Sounds like it would be worth making this part of the core distribution, though -- a number of people sound like they're after something like this.. Committed CocoonPipelineCronJob plus some commented out sample configuration snippets in cron.xconf. It is configured something like this (trigger not shown) : component role=org.apache.cocoon.components.cron.CronJob/pipeline-test class=org.apache.cocoon.components.cron.CocoonPipelineCronJob logger=cron.pipeline pipelinesamples/hello-world/hello.xhtml/pipeline /component enjoy regards Jeremy smime.p7s Description: S/MIME cryptographic signature
DO NOT REPLY [Bug 29462] New: - Add what information to source files
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=29462. 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=29462 Add what information to source files Summary: Add what information to source files Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This was discussed in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108667813326352w=2 The idea is to add what ID strings to source files, containing the Subversion URL that allows one to retrieve the appropriate version of the source file, for example: public static final String WHAT_ID = @(#) SomeFile.java http://subversion-url-here;; Then, the what command (http://www.hmug.org/man/1/what.html) can be used to extract this info from source files, or from jar files: unzip -p somejar.jar | what will print the WHAT_IDs contained in the jar. This will allow users to know exactly which versions of source files have been used to build jars that they're using (assuming the files have been committed to SVN before compiling). A script or ant task will be needed to make sure all source files contain this info.
Re: Use of the what command with java code
Le 9 juin 04, à 12:14, Stefano Mazzocchi a écrit : ...Even better would be to have directly the URL that would return you the source file. SVN is already web based, you don't need viewcvs or anything else, just the right URL (do a tcpflow dump of the SVN client over http and you know what I mean) Great idea - I have added this to the spec in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=29462 -Bertrand
Re: Including source files in jars
Yes, this makes sense. I ran into the same thing with 2.1.4 because I patched our copy and submitted the patches (which are now in 2.1.5). I did have trouble finding a home for the patches because we don't keep Cocoon in our CVS. However, I still think this is a good idea for snapshot jars that Cocoon includes. I't's been a pain finding some of the source code for those in the past. Ralph At 6/9/2004 12:48 AM, you wrote: Ok, I think not to have explained the use case clearly. It is actually very close to what you explain about dependent projects. This feature is not useful for us Cocoon devs, but for project developpers that use unreleased versions. We have a project here in my company with complex recursive forms which required me to extend CForms. I do not work directly on the project, but provide its developpers with new versions of forms-block.jar that run with the official 2.1.5. The purpose of including the sources in jar files is for the developpers of this project to be able to know with no ambiguity what sources they use. Furthermore when these sources are not yet in Cocoon's CVS (don't worry, commits will come soon). These guys are in the office next to mine, so roundtrip time is fast and communication easy. Now consider a project made for a remote customer, which required to use a non-released version because of a bug to fix or a few feature to implement. One year after the project is finished, the customer calls back because some errors occur. How do you know what sources the project actually uses? Just ask the customer to send you the contents of WEB-INF/lib! So, to restate it, this feature is of little use for us Cocoon devs but very useful for users of CVS snapshots. It's just useful for them as it would be useful for us to have source of snapshots of dependent projects in the corresponding jars. Does it make more sense? Sylvain
Re: Including source files in jars
Ralph Goers wrote:
Yes, this makes sense. I ran into the same thing with 2.1.4 because I
patched our copy and submitted the patches (which are now in 2.1.5). I
did have trouble finding a home for the patches because we don't keep
Cocoon in our CVS.
However, I still think this is a good idea for snapshot jars that
Cocoon includes. I't's been a pain finding some of the source code for
those in the past.
Yes, this is a good idea. We could encourage this practice whenever a
snapshot jar is added to the CVS.
However, since the build of other products certainly doesn't allow this
automatically, it will require an additional manual step for people
building the snapshot. IMO, this is worth it.
What do other think? Do we enforce this rule?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [cforms] Simple XML binding
Daniel Fagerstrom wrote: I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter between a form object and a simple XML format that can be used without needing to wriite a binding definition. snip/ I also checked in a sample, (a variant of the binding sample), that show how to use the adapter. WDYT? cool stuff! -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: REQ: An escapeXml attribute in JXT macro/script output
Thanks for the reply. I have a similar workaround, but I do consider it a
'workaround'. If we
find that a significant number of users are doing things like this, then that tells me
simpler,
'built-in' approach would be more appropriate. Maybe this is not the case though...
if I'm the
only one doing this, then there's certainly no need to build it into the framework ;)
--- Leszek Gawron [EMAIL PROTECTED] wrote:
Terry Brick wrote:
Hello,
This request is carried over from the users list regarding introducing XML from a
variable/component into the JXT output stream.
For example, let's say I have Java bean with a String property that holds XML
text. If, in my
template, I do something like...
${MyBean.XML}
... Then all of the XML characters are escaped.
For example,
para
..becomes..
lt;paragt;
I would think that for most Cocoon users, this is undesirable behavior most of the
time.
The current workaround is to have the bean property return a DOM Document instead
of a String.
However, in many cases, other than to accomodate this workaround, I have no other
need to
create a
DOM document within my Java component so it seems like there could be some
unecessary
overhead
associated with doing that. I guess that depends on how Cocoon handles the doc...
maybe it's
a
wash.
Anyway, an escapeXml=true/false attribute on the JX output tags (similar to
JSTL) would
certainly be handy IMO.
Thanks!
Solution:
function stringToSAX( str, consumer, ignoreRootElement ) {
var is = new Packages.org.xml.sax.InputSource( new java.io.StringReader( str )
);
var ignore = ( ignoreRootElement == true );
var parser = null;
var includeConsumer = new org.apache.cocoon.xml.IncludeXMLConsumer( consumer,
consumer );
includeConsumer.setIgnoreRootElement( true );
try {
parser = cocoon.getComponent(
Packages.org.apache.excalibur.xml.sax.SAXParser.ROLE );
parser.parse( is, includeConsumer );
} finally {
if ( parser != null ) cocoon.releaseComponent( parser );
}
}
put it into session by
cocoon.session.setAttribute( saxer, stringToSAX );
implement a jx:macro:
jx:macro name=xmlize
jx:parameter name=value/
jx:parameter name=ignoreRoot default=false/
jx:set var=ignored value=${cocoon.session.stringToSAX( value,
cocoon.consumer,
ignoreRoot )}/
/jx:macro
use it like this:
xmlize value=${xmlVal} ignoreRoot=true/
and you're done.
LG
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Re: [cforms] Simple XML binding
Reinhard Poetz wrote: Daniel Fagerstrom wrote: I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter between a form object and a simple XML format that can be used without needing to wriite a binding definition. Thank you very much! I think this is a very valuable addition to Cocoon Forms and is the answer for many form applications which have straight binding. One question - why do you make this explicit: // get the documentURI parameter from the sitemap which contains the // location of the file to be edited var documentURI = cocoon.parameters[documentURI]; // get the XML adapter var xmlAdapter = form.getXML(); // parse the document to a widget tree var pipeUtil = cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil); pipeUtil.processToSAX(documentURI, null, xmlAdapter); and don't hide it in the form.getXML() function? e.g. var xmlAdapter = form.getXML( cocoon.parameters[documentURI] ); Agree :) I have added loadXML(uri) and saveXML(uri) to the api, now the example look like: // get the documentURI parameter from the sitemap which contains the // location of the file to be edited var documentURI = cocoon.parameters[documentURI]; // populate the form form.loadXML(documentURI); // show the form to the user until it is validated successfully form.showForm(form2-display-pipeline); // save the content of the form to a file form.saveXML(makeTargetURI(documentURI)); // show the xml generated from the form cocoon.sendPage(form2simpleXML-success-pipeline, form.getXML()); Here we also save the content to a file (or any modifiable source). The getXML() method is still part of the api as it gives the possiblity to use the content handler and xmlizable interfaces, and also to set properties for the adapter, (this far only the choise of locale for string conversion). /Daniel
Re: [cforms] Simple XML binding
Bruno Dumon wrote: On Wed, 2004-06-09 at 10:36, Daniel Fagerstrom wrote: snip/ In such case, that is not what I want to achieve, I think that the XML format should be locale independent (at least as default), I think so too how do one implement that? simply use Locale.US? Seem like a better idea, I changed the code to use Locale.US as default. /Daniel
Re: cvs commit: cocoon-2.1 status.xml
[EMAIL PROTECTED] wrote: cziegeler2004/06/09 04:59:23 ... Log: Add profiling/debugging API for the sitemap. :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
[Authentication-fw] Per-user unique authentication
Hi cocooners ! For a project, I must have a unique authentication per user. If I have well understood, currently, the auth-fw is based on session existency to check if a user is authenticated. But it doesn't prevent users to use several browsers (and/or browser windows) on different locations to authenticate twice. I had a discussion with Sylvain (many thanks to him !), that proposed to use the org.apache.cocoon.environment.Context to store a map of authenticated users, as a reference to check for extra authentication. It would be very interesting if it could be embeded into, maybe a org.apache.cocoon.webapps.authentication.components.Authenticator, to fit the actual auth-fw. And in addition the user authentication context stored in the context map should be aware of session invalidation, to clear itself from the map, and maybe deal with some other cleaning (two asses kicked with one foot ;)). Is this the right way to go ? Is there another better way ? Many thanks ! -- Olivier Billard
Re: REQ: An escapeXml attribute in JXT macro/script output
Terry Brick wrote: Thanks for the reply. I have a similar workaround, but I do consider it a 'workaround'. If we find that a significant number of users are doing things like this, then that tells me simpler, 'built-in' approach would be more appropriate. Maybe this is not the case though... if I'm the only one doing this, then there's certainly no need to build it into the framework ;) I have also found it a workaround and surely cocoon needs a templating language with taglibs support. That has already been mentioned on the list but no steps were taken. That is why I proposed you that solution. -- Leszek Gawron [EMAIL PROTECTED]
RE: [Authentication-fw] Per-user unique authentication
Olivier Billard wrote: Hi cocooners ! For a project, I must have a unique authentication per user. If I have well understood, currently, the auth-fw is based on session existency to check if a user is authenticated. But it doesn't prevent users to use several browsers (and/or browser windows) on different locations to authenticate twice. I had a discussion with Sylvain (many thanks to him !), that proposed to use the org.apache.cocoon.environment.Context to store a map of authenticated users, as a reference to check for extra authentication. It would be very interesting if it could be embeded into, maybe a org.apache.cocoon.webapps.authentication.components.Authentica tor, to fit the actual auth-fw. And in addition the user authentication context stored in the context map should be aware of session invalidation, to clear itself from the map, and maybe deal with some other cleaning (two asses kicked with one foot ;)). Is this the right way to go ? Is there another better way ? Good questions :) From your description I guess that when a user uses a second browser the user has to authenticate again. It is not possible to know that this user is the same one than someone else who has already logged in. Or do I oversee something? You can write your own Authenticator to test if this user is already logged in - for example by storing the information in the context. But of course this user gets his own session and there his own session context where data might be stored. If you want that this two users (who are actually the same :) ) share the same data you have to do this yourself and store/retrieve the data from the appropriate places. I think you can handle the invalidation using a session listener. HTH Carsten
Re: Groovy, Flow Page Templates
Bertrand Delacretaz wrote:
Le 8 juin 04, à 21:16, Tony Collen a écrit :
... map:generate type=script src={1}.gy/
...
sendPageAndWait(confirm_register.gsp, {bizdata : bizdata});
...
How would one go about getting:
a) The bizdata object
b) The continuation id
I guess the question is where does sendPageAndWait store bizdata, but
I don't know ;-)
If it's request attributes, you'll be able to get at them from Groovy
through the objectModel and then the request object. And the
ScriptableGenerator can be easily ehanced to make more stuff available
directly to Groovy scripts.
Note that, last time I checked, the execution of Groovy-based pages was
*very* slow, like down to 2 pages per second only. It might not be a
Groovy problem, but rather our naive implementation which probably
initializes a lot of stuff and interprets the Groovy script every time.
There are better ways to embed Groovy than BSF tough [1], so it might be
worth writing something better in someone's Copious Free Time...
Yeah, I noticed this in my testing. The BSF is great for prototyping
Generators. I also absolutely love Groovy's syntax for XML. I saw that there
was stuff about making it all cacheable, which is obviously good. I'm still
trying to search for The Perfect Template Language... the JX is nice, but it's
also nicer to have alternatives. Perhaps it's time to see what a
GroovyGenerator can do.
Tony
Re: Groovy, Flow Page Templates
Le 9 juin 04, à 16:49, Tony Collen a écrit : ...Perhaps it's time to see what a GroovyGenerator can do. Well, if you have some free time I'd say: go for it!!! -Bertrand
Re: [Authentication-fw] Per-user unique authentication
Thanks for you answer, Carsten ! Details below : Carsten Ziegeler wrote: Olivier Billard wrote: Hi cocooners ! For a project, I must have a unique authentication per user. If I have well understood, currently, the auth-fw is based on session existency to check if a user is authenticated. But it doesn't prevent users to use several browsers (and/or browser windows) on different locations to authenticate twice. I had a discussion with Sylvain (many thanks to him !), that proposed to use the org.apache.cocoon.environment.Context to store a map of authenticated users, as a reference to check for extra authentication. It would be very interesting if it could be embeded into, maybe a org.apache.cocoon.webapps.authentication.components.Authentica tor, to fit the actual auth-fw. And in addition the user authentication context stored in the context map should be aware of session invalidation, to clear itself from the map, and maybe deal with some other cleaning (two asses kicked with one foot ;)). Is this the right way to go ? Is there another better way ? Good questions :) From your description I guess that when a user uses a second browser the user has to authenticate again. Yes. It is not possible to know that this user is the same one than someone else who has already logged in. Or do I oversee something? No you're right, and that exactly the problem :) You can write your own Authenticator to test if this user is already logged in - for example by storing the information in the context. But of course this user gets his own session and there his own session context where data might be stored. If you want that this two users (who are actually the same :) ) share the same data you have to do this yourself and store/retrieve the data from the appropriate places. Since I don't want any user to try to login without disabling previous session, no problem here :) I think you can handle the invalidation using a session listener. Thanks for confirming the idea ! I'll go this way ! -- Olivier
Re: Use of the what command with java code
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Even better would be to have directly the URL that would return you the source file. SVN is already web based, you don't need viewcvs or anything else, just the right URL (do a tcpflow dump of the SVN client over http and you know what I mean) Hey, cool idea! We could even have the what result be formatted as HTML linking to source files! We could have a getDescription() method returning an RDF that encoded all that ;-) -- Stefano, who candidates himself for the FS-of-the-month award with this. smime.p7s Description: S/MIME Cryptographic Signature
*Cough* Download Size *Cough*
Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? That's a lot to download no matter how you put it. I mean I just got DSL, and the fastest I can suck it down in 90KB/s and weighing in at 45MB download that takes a little over 8.5 minutes. I can only imagine what it would be like if I was still on dial-up: over 2 hours with a good connection. To tell the truth that is a little intimidating to me. It almost seems as if there is 45MB of stuff to understand before I can be productive (I know this is not the case, but consider it from a user's perspective). Is there anything that can be done to minimize this at all? -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: Releasing Lenya 1.2
Stefano Mazzocchi wrote: Rolf Kulemann wrote: After the vote we have to do many more things like doing the incubator request. It would be fine if someone can give me a hint how the requests for endorsement and release should look like. Eh, good question, I've never done it before. Let's ask the incubator PMC. (lets try and keep everything incubator-related that doesn't need to be private on [EMAIL PROTECTED] there pleez!) See: http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting+the+Incubator In summary: * make sure the incubator statusfile for lenya is up-to-date and all bullets checked; * lenya people ask incubator pmc to vote on incubator sign-off on [EMAIL PROTECTED] after gaining internal consensus they're done incubating; * if incubator pmc agrees everything is done, lenya and cocoon are notified and take care of all the relevant details (like moving the incubator status file to the appropriate location, updating website, filing infrastructure requests, etc). besides the incubator policy docs, you can see application of them to several projects in the [EMAIL PROTECTED] mailing list archives. cheers! - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: *Cough* Download Size *Cough*
Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? That's a lot to download no matter how you put it. I mean I just got DSL, and the fastest I can suck it down in 90KB/s and weighing in at 45MB download that takes a little over 8.5 minutes. I can only imagine what it would be like if I was still on dial-up: over 2 hours with a good connection. To tell the truth that is a little intimidating to me. It almost seems as if there is 45MB of stuff to understand before I can be productive (I know this is not the case, but consider it from a user's perspective). Is there anything that can be done to minimize this at all? I'm pretty sure that when Real Blocks [1] are functional, you'll only have to download the blocks you want, so a default core Cocoon will generally be all you get. Of course, who knows how far off Real Blocks are :) [1] http://wiki.cocoondev.org/Wiki.jsp?page=GT2003RealBlocks Tony
Future compatibility warning
Just before I switch off to going pure Java 1.4 with the cocoon build, I
thought I would warn you of a future compatibility issue:
[javac]
F:\projects\cocoon-2.1.5\src\java\org\apache\cocoon\xml\dom\DocumentWrapper.java:48:
org.apache.cocoon.xml.dom.DocumentWrapper is not abstract and does not
override abstract method
renameNode(org.w3c.dom.Node,java.lang.String,java.lang.String) in
org.w3c.dom.Document
[javac] public class DocumentWrapper implements
org.w3c.dom.Document, XMLizable {
[javac]^
[javac] 1 error
In other words, in Java 1.5 there will be a new method on
org.w3c.dom.Document named renameNode(Node, String, String)
It would probably be worth it just to add this method to our wrapper,
and have it do nothing--that way there won't be any issues whatsoever.
--
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning.
- Rich Cook
Problem with compile defaults
If someone is experimenting with Java 1.5 on their system (like me), the Java 1.5 compiler will cause a problem because you specify a target of 1.3 without specifying the source parameter. The source parameter is the most important aspect, and you will have a target of 1.2 if you specify a source of 1.2 or 1.3. Please do not use the target parameter on javac without a corresponding source parameter. Problematic: javac -target 1.3 This will cause problems if the default source parameter changes (as it does from 1.4 to 1.5beta1 to 1.5beta2. Best: javac -source 1.3 This will allow the compiler to generate the corresponding target automatically and you don't get bitten by the default source changes. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: *Cough* Download Size *Cough*
Tony Collen wrote: I'm pretty sure that when Real Blocks [1] are functional, you'll only have to download the blocks you want, so a default core Cocoon will generally be all you get. Of course, who knows how far off Real Blocks are :) [1] http://wiki.cocoondev.org/Wiki.jsp?page=GT2003RealBlocks Tony What about having all the blocks in JAR or ZIP file format on the server with an ANT task to download and determine what we need. That way only the blocks we want are still downloaded, and we don't necessarily change the archive structure. The thought being that the ANT task would download and unzip the source block in the proper location in the archive. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: *Cough* Download Size *Cough*
Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. ;-) Vadim [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=26456
Re: [cforms] Simple XML binding
Daniel Fagerstrom wrote: I have added loadXML(uri) and saveXML(uri) to the api, now the example look like: // get the documentURI parameter from the sitemap which contains the // location of the file to be edited var documentURI = cocoon.parameters[documentURI]; // populate the form form.loadXML(documentURI); // show the form to the user until it is validated successfully form.showForm(form2-display-pipeline); // save the content of the form to a file form.saveXML(makeTargetURI(documentURI)); // show the xml generated from the form cocoon.sendPage(form2simpleXML-success-pipeline, form.getXML()); Here we also save the content to a file (or any modifiable source). The getXML() method is still part of the api as it gives the possiblity to use the content handler and xmlizable interfaces, and also to set properties for the adapter, (this far only the choise of locale for string conversion). /Daniel Very nice! -- Reinhard
Re: *Cough* Download Size *Cough*
Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. ;-) Vadim [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=26456 You are a truly sick man. ;P -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Minor issue with XHTML sample
Browsing the following with MSIE: http://localhost/webapp/samples/hello-world/hello.xhtml I got the following message (note displays correctly in Mozilla): The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. Use of default namespace declaration attribute in DTD not supported. Error processing resource 'http://localhost/webapp/samples/hello-world/hello.xhtml'. Line 17, Position 7 htmlheadtitleHello/titlelink rel=stylesheet type=text/css href=/styles/main.css //headbody --^ -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Minor issue with WordDoc example
The URL: http://localhost/webapp/samples/hello-world/hello-worldml.doc returns the mime type: text/xml and Word XP can't open it (Tries to treat it as a simple text document) -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Nice Error Page
Things have definitely improved with the error reporting. The new error page is quite nice and much less garish. Pretty helpful too. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
RE: Minor issue with WordDoc example
Hi Berin, could you please state the version you are using in your reports? I assume ( because of your download mail) that you are using 2.1.5. Carsten -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch Sent: Wednesday, June 09, 2004 7:09 PM To: [EMAIL PROTECTED] Subject: Minor issue with WordDoc example The URL: http://localhost/webapp/samples/hello-world/hello-worldml.doc returns the mime type: text/xml and Word XP can't open it (Tries to treat it as a simple text document) -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: Minor issue with WordDoc example
Carsten Ziegeler wrote: Hi Berin, could you please state the version you are using in your reports? I assume ( because of your download mail) that you are using 2.1.5. Oh, ok. Yes, everything is from the most recent release: 2.1.5. It seems the flow examples are broken (no content shows up at all!). -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: *Cough* Download Size *Cough*
On 09 Jun 2004, at 18:27, Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. We'll add jar'ed sources of the JDK with that as well, don't we? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Minor issue with WordDoc example
Berin Loritsch wrote: Carsten Ziegeler wrote: Hi Berin, could you please state the version you are using in your reports? I assume ( because of your download mail) that you are using 2.1.5. Oh, ok. Yes, everything is from the most recent release: 2.1.5. It seems the flow examples are broken (no content shows up at all!). Further report on that: Tomcat 5 was at 128MB memory usage and nothing was coming back from Tomcat. So, the problem was the server, not cocoon (this time). -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: *Cough* Download Size *Cough*
Steven Noels wrote: On 09 Jun 2004, at 18:27, Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. We'll add jar'ed sources of the JDK with that as well, don't we? We might as well include some operating system source while we're at it :D Tony
Re: Heads up, MSIE weirdness
Berin Loritsch wrote: Just an FYI, MSIE (known for adherance to standards, yeah right) does not behave in a rational manner when it sees the XML header even if the rest of the system is HTML. Case and point is the linotype sample included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but because Cocoon 2.1.5 includes the header ?xml version=1.0 encoding=ISO-8859-1 ? at the top, MSIE (version 6) renders it as XML. If that header were not there, everything would be ok. Hmm, does MSIE barf on other XHTML like this? (not served by Cocoon) Tony
Re: *Cough* Download Size *Cough*
Tony Collen wrote: Steven Noels wrote: On 09 Jun 2004, at 18:27, Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. We'll add jar'ed sources of the JDK with that as well, don't we? We might as well include some operating system source while we're at it :D Which one? You'll have to include source code for Linux, *BSD, MacOSX, Windows, etc.--you know just to make sure the sockets are working properly. Of course by this time the download will be in the GB region and will completely be impractical to all who might want to use it. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: Heads up, MSIE weirdness
Tony Collen wrote: Berin Loritsch wrote: Just an FYI, MSIE (known for adherance to standards, yeah right) does not behave in a rational manner when it sees the XML header even if the rest of the system is HTML. Case and point is the linotype sample included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but because Cocoon 2.1.5 includes the header ?xml version=1.0 encoding=ISO-8859-1 ? at the top, MSIE (version 6) renders it as XML. If that header were not there, everything would be ok. Hmm, does MSIE barf on other XHTML like this? (not served by Cocoon) Huh. I saved it as an XML file, and then opened the .XML file, and all was OK (no css styling). The thing is, I checked it out on FireFox (Mozilla's new browser), and the mime type sent from the server was text/html--so that should not have been the problem. -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook
Re: Heads up, MSIE weirdness
Berin Loritsch wrote: Tony Collen wrote: Berin Loritsch wrote: Just an FYI, MSIE (known for adherance to standards, yeah right) does not behave in a rational manner when it sees the XML header even if the rest of the system is HTML. Case and point is the linotype sample included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but because Cocoon 2.1.5 includes the header ?xml version=1.0 encoding=ISO-8859-1 ? at the top, MSIE (version 6) renders it as XML. If that header were not there, everything would be ok. Hmm, does MSIE barf on other XHTML like this? (not served by Cocoon) Huh. I saved it as an XML file, and then opened the .XML file, and all was OK (no css styling). The thing is, I checked it out on FireFox (Mozilla's new browser), and the mime type sent from the server was text/html--so that should not have been the problem. Yep, MSIE likes to ignore mime-type headers because it thinks it knows better which is annoying. I have a friend who had this sort of problem a year ago with MSIE and PDFs, mainly if the file extension is not PDF, no matter what you send in headers, it will display the file as text or whatever. I tried this, thinking it would help: map:match pattern= map:redirect-to uri=index.html/ /map:match map:match pattern=index.html map:generate src=index.xhtml/ map:transform type=cinclude/ map:serialize/ /map:match And MSIE *still* displays xml. This makes me really angry, in a caffeine-induced sort of way. The problem with removing the xml declaration is that I think it will ruin any sort of xhtml compliance. :( Tony
Re: Heads up, MSIE weirdness
On 09.06.2004 20:50, Berin Loritsch wrote: Just an FYI, MSIE (known for adherance to standards, yeah right) does not behave in a rational manner when it sees the XML header even if the rest of the system is HTML. Case and point is the linotype sample included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but because Cocoon 2.1.5 includes the header ?xml version=1.0 encoding=ISO-8859-1 ? at the top, MSIE (version 6) renders it as XML. If that header were not there, everything would be ok. Yes, I already came across this and files it as bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=29009. What's strange: the start page is also XHTML and it works. Joerg
Re: cvs commit: cocoon-site/site versioning.html history.html incubation.html index.html whoweare.html
On 09.06.2004 22:29, [EMAIL PROTECTED] wrote: Added: site versioning.html Log: website update (mostly only the copyright year) Hope that was not to early. Joerg
Re: *Cough* Download Size *Cough*
Just for grins I ran a du on Cocoon-2.1.5. These numbers don't necessarily correspond to what is in the zip/gzipped tar as source should compress better than jars, but this is what I got. To summarize, out of 95MB 75MB is source and 61MB is in blocks. About 10% (9MB) is scratchpad. The lib directory takes up abuot 12MB. I'd expect that to be pretty much the same inside the zip/gzipped tar, so the vast majority of the rest is probably the compressed source. One way to reduce the size of the download is to remove the dependent jars. This has been discussed here many, many times. However, I'm wondering how much scratchpad stuff should disappear. I haven't looked at what is in it, but shouldn't there be some rule about how long something can stay there? For the root directory I got: 8 blocks.properties 4 build.bat 8 build.properties 4 build.sh 4 build.xml 16 cli.xconf 8 cocoon.bat 8 cocoon.sh 4 CREDITS.txt 4 DESKTOP.INI 8 forrest.properties 40 gump.xml 8 INSTALL.txt 12 KEYS 804 legal 12752 lib 4 README.txt 75652 src 112 status.xml 3500tools I then ran it again on the src subdirectory: 61768 blocks 16 confpatch 532 deprecated 4916documentation 4884java 20 mocks 112 resources 100 samples 520 test 2780webapp Finally, I ran it against blocks: 188 apples 176 asciiart 328 authentication-fw 1720axis 2788batik 900 bsf 824 chaperon 492 cron 1056databases 7040deli 156 eventcache 1568fop 3708forms 360 hsqldb 260 html 860 itext 376 javaflow 212 jfor 172 jms 180 jsp 176 linkrewriter 884 linotype 552 lucene 948 mail 472 midi 156 naming 1832ojb 56 paranoid 1024petstore 56 php 1504poi 2920portal 896 portal-fw 200 profiler 268 proxy 148 python 236 qdox 360 repository 9804scratchpad 5364serializers 376 session-fw 1508slide 448 slop 320 stx 192 swf 320 taglib 384 tour 460 velocity 212 web3 992 webdav 3512woody 708 xmldb 1112xsp Berin Loritsch said: Tony Collen wrote: Steven Noels wrote: On 09 Jun 2004, at 18:27, Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. We'll add jar'ed sources of the JDK with that as well, don't we? We might as well include some operating system source while we're at it :D Which one? You'll have to include source code for Linux, *BSD, MacOSX, Windows, etc.--you know just to make sure the sockets are working properly. Of course by this time the download will be in the GB region and will completely be impractical to all who might want to use it.
Re: Heads up, MSIE weirdness
Tony Collen wrote:
Berin Loritsch wrote:
Tony Collen wrote:
Berin Loritsch wrote:
Just an FYI, MSIE (known for adherance to standards, yeah right) does
not behave in a rational manner when it sees the XML header even if
the rest of the system is HTML. Case and point is the linotype sample
included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but
because Cocoon 2.1.5 includes the header
?xml version=1.0 encoding=ISO-8859-1 ?
at the top, MSIE (version 6) renders it as XML. If that header were
not there, everything would be ok.
Hmm, does MSIE barf on other XHTML like this? (not served by Cocoon)
Huh. I saved it as an XML file, and then opened the .XML file, and
all was OK (no css styling). The thing is, I checked it out on
FireFox (Mozilla's new browser), and the mime type sent from the server
was text/html--so that should not have been the problem.
Yep, MSIE likes to ignore mime-type headers because it thinks it knows
better which is annoying.
And there's sometime some even weirder behaviours, as when IE considers
the mime-type, it considers it only *once* for a given URL. Which
sometimes make it barf on malformed XML when for some (valid) reason the
content-type of the same URL changes from XML to HTML.
I have a friend who had this sort of problem a year ago with MSIE and
PDFs, mainly if the file extension is not PDF, no matter what you send
in headers, it will display the file as text or whatever.
Or worse, as a blank page!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Minor issue with WordDoc example
On 09.06.2004 19:08, Berin Loritsch wrote: The URL: http://localhost/webapp/samples/hello-world/hello-worldml.doc returns the mime type: text/xml and Word XP can't open it (Tries to treat it as a simple text document) Isn't the target of this sample Word 2003? Joerg
Re: Minor issue with XHTML sample
On 09.06.2004 18:59, Berin Loritsch wrote: Browsing the following with MSIE: http://localhost/webapp/samples/hello-world/hello.xhtml Use of default namespace declaration attribute in DTD not supported. IE insists on the xhtml namespace, which was missing. Joerg
flow: release resources after the view is generated
One of the users had reported an example that needs resolving. As it is
something that affects also me I didn't want to wait for him to post
some questions.
Imagine you obtain some resources that need to be valid during view
rendering. A hibernate session is a good example. You need to have it
open during view generation. Otherwise you will not be able to use lazy
initialized collections. The problem is that cocoon.sendPage does not
wait for the view generation to be finished:
var session = obtainHibernateSession();
var bizData = getSomeBizDataUsingSession( session );
cocoon.sendPage( view.jx, { biz: bizData } );
session.close();
This example will throw if bizData contains lazy collections because
when they will be accessed session will already be closed. AFAIU there
is no way to call any piece of code when you are sure that view
rendering has finished. This is a very common case I think so this
should be solved somehow.
LG
Re: Test -- please ignore
David Crossley wrote: Sylvain Wallez wrote: Ok, so the problem isn't on my side of the pipe. I just hope the roundtrip time will come again to a smaller value, as fast interaction is key for groups like ours. Yes, i too have been very confused by mail lately. I just sent a message to [EMAIL PROTECTED] to make sure they are aware of the issue. Infrastructure are asking for more information like an example mail header and timing example. --David
Re: *Cough* Download Size *Cough*
Berin Loritsch wrote: Tony Collen wrote: Steven Noels wrote: On 09 Jun 2004, at 18:27, Vadim Gritsenko wrote: Berin Loritsch wrote: Is there any reason the Cocoon source distribution has to be about the same size download as a current JVM? Don't worry, we already discussed this matter with Carsten [1] and decided that next version of Cocoon will come with bundled JDK. We'll add jar'ed sources of the JDK with that as well, don't we? We might as well include some operating system source while we're at it :D Which one? You'll have to include source code for Linux, *BSD, MacOSX, Windows, etc.--you know just to make sure the sockets are working properly. Hey, hold on! We can't include Linux, as it is GPLed, so the only choice is *BSD! Vadim
Re: Heads up, MSIE weirdness
On Jun 9, 2004, at 2:50 PM, Berin Loritsch wrote: included with Cocoon 2.1.5. MSIE identifies it as an HTML page, but because Cocoon 2.1.5 includes the header ?xml version=1.0 encoding=ISO-8859-1 ? at the top, MSIE (version 6) renders it as XML. If that header were not there, everything would be ok. When MSIE has an XML header in an xhtml document, that document will never be rendered in standards-compliant mode, rather it will be rendered in quirks mode. Yet another thing to watch out for :) -pete
