Re: Templating: experiments with Conal's html-to-xslt transform
Hi Christian, ...I don't know, which is more complicated, can't tell. But I took your example and wrote it in TAL. See http://wiki.bitflux.org/Templates_TAL_Example for details... Thanks, this looks really interesting. I'll have a closer look ASAP. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: JXTemplateGenerator
Le 11 déc. 04, à 00:57, Christopher Oliver a écrit : ..."General consensus" has turned out to be incorrect on many occasions. What I see is that some people, such as Stefano, are looking to build a better templating system while others are contemplating what appears to be pointless refactoring... If the only goal is for these people to become more comfortable with the code by refactoring, and especially if they're creating new tests along the way it I'm happy. But I understand the refactoring can seem pointless to you as you know this code much better. ...Any 3000-lines java source file *is* scary in my book, detailed analysis would probably show that you code is indeed well structured, but looking at it as it is now is scary for many people, myself included. OK, but the size of the source file has no effect on the behavior of the classes it contains. If someone wants to convert inner to external classes it is a trivial and mindless exercise. In fact, I would hardly call it refactoring... Point taken, it's more like restructuring (damn, is there a function key in IDEA to do this? ;-) The important thing for me is not really how the code looks though, but how the people who are taking charge of it perceive it. ... On the other hand the issues that Stefano raised bring up real problems that are not addressed by JXTG at all (nor any of the suggested alternatives)... Ok - there's probably more to do, but in the meantime JXTG is an important component of Cocoon, so whatever big or small work people do to improve it must be encouraged. ...It's not personal, Bertrand. If someone does good work or makes a valid point I will give them proper respect. If not, well, I'm not teaching grade school and it's not my job to sugar coat it. I know, but we're all the grade school student of someone else here, depending on which area of expertise you consider. So we have to be careful not to break the (sometimes fragile) links which hold this great community together. Thanks for your constructive reply (and for the initial comments about JXTG by the way, they will help a lot). -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: JXTemplateGenerator
Le 10 déc. 04, à 17:29, Christopher Oliver a écrit : ...The funniest post of all was this http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110210971210386&w=2. I mean, give me break. That is just plain silly Can't swallow this one without reacting, sorry - wrong tone, and there is a general consensus that JXTG needs refactoring, I find it very unfair of you to pick on Tony specifically. Any 3000-lines java source file *is* scary in my book, detailed analysis would probably show that you code is indeed well structured, but looking at it as it is now is scary for many people, myself included. You've been quiet for a while, people are willing to take over to ensure JXTG's future (because it's a great tool, we *are* thankful to you for this), they're doing their best and we're starting to see good things coming out of this. So please respect their work - as much as we respect you and your work. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: AW: Templating: experiments with Conal's html-to-xslt transform
Le 10 déc. 04, à 15:05, Merico Raffaele a écrit : Hi Bertrand As you maybe remember, this level of SOC is a main topic of my job. Although I do not understand all details of the attribute-based transformation, I actually see the following limitations (L) and disadvantages (D):.. Thanks for speaking up! L) The HTML-template to XSLT transformation is limited to one "level" of data access (i.e. what do you do if you want to process XPATH expressions that are in the XML-data stream?). Hmm...go to straight XSLT maybe? I currently don't envision using this templating system for more than simple/common stuff: keep it simple for simple cases, move up to XSLT for the rest. Actually it would be easy to include partial XSLT transforms in our templates, so that the web designer can ask an expert to write the hard stuff. L) How would you solve case specific (if) rendering within a for-each="..."? Consecutive div having @case are converted to xsl:choose With a default case of course Is that what you mean? ...D) I'm not sure if the web designers would be very happy to work with a mixed XSL/XPATH syntax, that's not familiar to them (i.e. apply-templates="node()"/> or [EMAIL PROTECTED]). The node() thing can be easily eliminated by making it the default value. For the rest, I think the advantages in terms of implementation far outweigh the disadvantages, people will have to learn some syntax anyway. And not inventing a new syntax means using one that is documented, there's tons of XPath info out there. ...D) This approach needs an additional transformation step. Yes, but it's certainly cacheable. ...In my opinion for the web designer it would be enough if they would have basic tags of procedural logic like and bundled with unlimited XPATH capabilities. I'm currently porting my "static" template language based on XSLT/XPATH 1.0 to XSLT/XPATH 2.0. As soon it is mature I will make it available for reflection to this list... Bring it on, it doesn't need to be mature, experimental is good enough! Release early, release often... -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
Le 10 déc. 04, à 14:44, Upayavira a écrit : ...I like this kind of approach, and am implementing a similar system at the moment... Great! Let's make this a documented/mainstream part of Cocoon, it's cheap to do and could make a big difference in the perception of Cocoon. I say "perception" because all this is already possible, we're just not showing it well enough I think. ...If we are fixated upon Dreamweaver, then we should work out how Dreamweaver extensions work, so that we can, with a bit of HTML and some Javascript, allow GUI access to the various elements we add into the page. This is, in effect, all that is done to give access to ASP, PHP, JSP, etc, in Dreamweaver, so I don't see why we couldn't do the same for some Cocoon markup (other than lack of interest!).. Right. Links to DW information are welcome, I've searched a bit but didn't find *the* reference on DW extensions. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
Le 10 déc. 04, à 14:34, Conal Tuohy a écrit : ...the "rules" section works in a different way than the rest. WDYT? I like the idea - in fact I had the same idea myself, but without adding a special "rules" section. I'm not sure I see the point in keeping it in a special div? I think it's good to allow people to define templates anywhere in the template file ... that way you can take a "design dummy" page and simply annotate it with these attributes without having to rearrange it... OTOH these "inline rules" might make the template more confusing to said dummy if he needs to work on the page again? My aim was to make it very clear that the rules are something special that one must learn (a bit) about, hence the separate section, with interspersed text a la literal programming, as the rules often need some explanation to the template author. Also, the separate section makes it clear that these rules can be called in any order. ...Another thing it really should have is a way to declare global parameters, passed to it from the sitemap. The old stylesheet I posted the other day automatically declares parameters "id" and "random" because they were common requirements of our templates, but it would be better to have to declare them explicitly. e.g. .. Right - but parameters often need default values, how about using for them? Where atl:keep means we want to keep it in the HTML output for debugging or indexing. ...I've done some work (not yet finished) on a similar transform to jxt, but without any pattern-matching templates so far (they're not impossible, just not quite so easy, because jxt doesn't already have pattern-matching templates)... Cool - but HTML to XSLT already looks very useful! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
Hi Christian, ...As I mentioned before (to one of stefano's posts), we did something similar, but with the TAL syntax. We convert that to XSLT with XSLT and then do the actual transformation with XSLT. It's the same idea as yours. I like the approach, even though it's not complete yet (our implementation) and we could certainly add some of your ideas... Sorry that I overlooked this, I was busy at the time and forgot about it (and we didn't meet at the non-happening Bern dinner, too bad - our day will come ;-). ...http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/ template.tal. Trying to jump into the head of the "average HTML template designer", to me this looks more complicated to understand than the example at http://wiki.apache.org/cocoon/HtmlToXsltExperiments. But you're setting attributes and I'm not, might account for some of the differences in (perceived) complexity. ...I don't say, our approach is better than yours, I didn't build an opinion on that. But maybe we could join efforts in it. As it's a pure XSLT implementation, the programming language behind doesn't really matter... Right, this is purely an XSLT thing. And joining efforts is good, even if it's only stealing ideas back and forth. I don't think we (Cocoon and bitflux) necessarily need to agree on everything, the resutling XSLT code won't be very big anyway. After replying to Daniel, I think having a "declarative rules" section or not in the template is a key point: IMHO the "copy some elements with minor changes" scenario is very common, the bindings.xml use-case in my example shows this. How would you handle this with your syntax? For example, transforming an XHTML input document by adding class attributes to and elements, without knowing where they appear in the input? In my example you just need to add a "declarative rules" section like this, assuming you have an apply-templates in the main section: Note that we can add text here to explain what's happening. Here we add a class attribute to p's Add a border to tables: -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Templating: experiments with Conal's html-to-xslt transform
Le 10 déc. 04, à 13:18, Daniel Fagerstrom a écrit :
...Looks nice to me. I would sugest that you put the xslt with some
working examples in the samples directory in the template block. So it
becomes easier to experiment with and enhance...
Sure - I was going to wait a bit for feedback though, as this is really
not specific to Cocoon, only to XSLT, so maybe some non-committers can
collaborate on the wiki before going to SVN.
...I think that puting a name space on the attribute directives is a
must. It makes it much easier to see what is code and what is data at
a glance. Also it cooperates much better with a strict XHTML scheme...
You're right, we need to namespace the attributes, it's much cleaner.
...I have not tested how it work or read the XSLT in detail, but I
wonder about the CSS rules in the style section, will not the XSLT try
to expand their bodies? You could use the same escaping as in XSLT
attributes:
body {{ font-family: Georgia,sans-serif; }}
No need to do that, the
Re: A novel way of finding Cocoon-driven sites on the web
Le 10 déc. 04, à 11:54, Steven Noels a écrit : ...Well, I'm subscribed on Google Newsalerts with the keywords "apache cocoon" and at least this week that's how I "discovered" http://www.computerworld.ch/ - I suspect Bertrand has the same subscription. ;-) Yes, I should have mentioned my source ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Templating: experiments with Conal's html-to-xslt transform
(ccing users@ as I'm sure many subscribers there could contribute to this experiment as well, please discuss on dev@) I've been playing [1] with Conal Tuohy's transform [2], to generate XSLT transforms based on simple attribute-based templates (HTML in this case, could be whatever) and I like it very much. Converting attribute-based templates to XSLT instead of processing them directly is fairly easy to implement, easy to use for the template writer yet powerful by giving access, when needed, to all XSLT constructs. And the syntax of attributes like for-each or apply-templates *is* XSLT, so Bob can ask Alice for help when needed ([3]). There's more info, including source code, on the wiki [1]. Feel free to use this page as a poor man's source code control system for improving this, if people like it we might want to include this our distribution? Compared to Conal's version, the current version allows "element templates" to be defined in the HTML template, they are similar to XSLT templates but much easier to write. I think this adds a lot of power while allowing the template to remain concise and modular, and "fairly" editable in visual tools. There has to be a compromise somewhere I think, converting XML data to HTML or another format *is* programming at some stage, the "100% visual" paradigm does not work for this in today's world IMHO. Comments/opinions/enhancements/flames are welcome (well, maybe not flames but if you think this sucks I'm all ears ;-) -Bertrand [1] http://wiki.apache.org/cocoon/HtmlToXsltExperiments [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110246247525208&w=2 [3] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110231970204971&w=2 smime.p7s Description: S/MIME cryptographic signature
A novel way of finding Cocoon-driven sites on the web
(at least those which have problems ;-) http://www.google.ch/search? q=%22internal%20server%20error%22%20org.apache.cocoon -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: how to list all sitemap components
Le 9 déc. 04, à 16:56, Upayavira a écrit : ...cd build/cocoon-2.1.7-dev/javadocs/ grep -rl SitemapModelComponent * Good one! Here's the pretty listing then: for i in $(grep -rl SitemapModelComponent * | grep org/apache) do echo $i | sed 's/\//\./g' | sed 's/\.html$//' done There's still a bit of junk left (package-frame etc) but it's a good start. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: how to list all sitemap components
Le 9 déc. 04, à 00:46, David Crossley a écrit : I am trying to create a list of all sitemap components in the Cocoon core and blocks... Doesn't qdox list the interfaces that a class implements? If it's the case, it should be possible to create a pipeline (using the qdox block) or use the qdox ant task to generate the list, by finding all classes which implement the Generator interface. Is there a way to uniquely identify the sitemap components by grepping the *.java e.g. perhaps a unique method name? Probably not, as the method could be implemented in a base class and as such not be visible in the derived class's source code. I'd go the qdox route, assuming it finds the inherited interfaces. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 09:49, Leszek Gawron a écrit : ... Because Microsoft did it, and there is so much Notepad data out there, the UTF-8 BOM became a de facto standard and then a de jure standard. (Although the BOM is optional.).. hmm...not sure if notepad is the kind of reference that we want to use here ;-) Anyway, I think most or all our XML files are UTF-8 with no BOM, so it's probably not a good idea to change. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 01:03, Leszek Gawron a écrit : ... + ... This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser... BOM has no meaning for UTF-8, see http://www.unicode.org/unicode/faq/utf_bom.html#BOM It is certainly better *not* to use it, to avoid any confusion. On unixish OSes, many tools check the first four bytes of a file and expect them to be -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] since we are at it, more irons in the template fire: Xenon
Le 8 déc. 04, à 22:03, Corin Moss a écrit : ...If there's interest, I'd be happy to provide an example of a skin / data aggregated document... Would you be able to package a small sample that we could add to the scratchpad? It might be interesting to have a live comparison of all these things that are being discussed these days (at least those that actually exist ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Attribute Driven Templates
Le 7 déc. 04, à 18:54, Sylvain Wallez a écrit : ...(hearing Stefano coming behind me, ready to shout "FS!!!" in my ears...) Nahh...his detector exploded yesterday, don't worry. ...Now going back to the annotated-HTML-to-XSL compiler that we (Anyware) wrote many years ago, it allows to mix both syntax, as attributes are simply translated to their XSLT equivalent, and you therefore can write plain XSLT in the HTML file (aargh! I hear Stefano coming!) A similar approach could be used for the template language with a single engine, by simply converting on the fly directives-as-attributes to directives-as-elements... Interesting - do you envision using XSLT for this conversion? Or doing it in java code? -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [FYI] Cocoon clones/ Cocoon homonyms
Le 7 déc. 04, à 21:49, [EMAIL PROTECTED] a écrit : What about this Cocoon: http://www.stratasys.com/software/cocoon/ Hmmm...If I need to start a project at some point I'll call it blrztproltkzht. I bet the name will stay unique for a while. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [FYI] Cocoon clones
Le 7 déc. 04, à 12:22, Sylvain Wallez a écrit : I just found http://xml-dtc.org/ which is a Cocoon clone written in... C! Popoon, Papaan, xml-dtc... maybe we should create a page title "Cocoon clones"? There's a page that started long ago in the wiki: http://wiki.apache.org/cocoon/SimilarServers -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Le 7 déc. 04, à 00:41, Stefano Mazzocchi a écrit : Bertrand Delacretaz wrote: ... -oo- Advantages: A1) There's only one implementation of the template and expression evaluation mechanisms. Ok A2) Bob can ask Alice for help with the templates, she knows them in and out as that's what she's using as well. Fair enough. A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became productive with the template language, which looks familiar. In a pinch, he can ask the trainee to make minor changes in DreamWeaver, in fact they saved a bunch by doing the prototype in this way. Again, fair enough. A4) The XML logical document will "never" change once it's done, as it contains all the data in presentation-independent format. Write it, test it, forget about it. Alice doesn't want the critical parts of their system to change too often. Yes, good strategy. It also allows this stage to be reused for another channel (say RSS feeds and the like). A5) The XML logical document can be reused to publish the RSS feed, the mobile WAP/WML version, the full-blown XHTML/CSS version, without bothering Alice who's a busy and expensive person. Damn, should read all of it before replying ;-) A6) Alice doesn't have to deal with the final customer who's always asking for "just a small change in the page layout". She leaves this to Bob for now, but they've considered training the customer to do this on his own, the templates are simple and isolated enough that he couldn't break anything anyway. Right. I have to say, as much as you arguments are convincing A4/A5/A6 are simply indicating why pipelines are useful, not why a common syntax between a generator and a transformer is ;-) Ok, but A6 is also a strong argument for having a *simple to use* template mechanism that can be used for presentation stuff. ...Your point (and interestingly enough Miles') is that having the same syntax for generation and transformation allows for A2 and A3... Yes, and also - this is very important - a *single implementation* for both of Alice's and Bob's concern. One set of tests, one set of docs, big savings overall. You just said OK to A1 but for me it's "great - big savings" ;-) My point is not if it's a good thing, my question is: can it be achievable without reinventing XSLT/STX and therefore without coming across with the same problems that it has and making it ackward to use for one side because we forced it to be the same on the other side?.. Very true. I believe it is doable *with some limitations*. If the new template language covers 95% of the use cases, we still have XSLT and custom (java) generators for the remaining 5%. Me, I *love* XSLT for complex stuff that deserves using it, but it took me a while to really grasp it. The new template language just needs to be good enough to enable the Alice and Bob scenario in common cases, no need to cover everything, as there are alternatives for the really complex cases. Disadvantages: D1) The XYZTransformer is probably slower than a well-written XSLT transform. But it's also much faster than the XSLT transform that Bob tried to write. He's only been doing XSLT for four weeks and just plain hates it. :-) Fair enough. But really, here your real point is that XSLT is painful and I can't agree more. But do you really think we can come up with something that doesn't end up looking just like STX? I think so - if we take TAL [1] as an example (for the available operations, I don't care about the syntax details at this point), I don't see anything missing, knowing that the pipeline is meant to start with Flowscript where you can prepare data if needed to make things easier. ...D4) Bob was initially confused about this generator/transformer thing, why both? Alice told him not to worry, generators are not his business anyway, he's only a Cocoon Transformer Template Designer (but a good one after only four weeks here). He'll understand when he grows up ;-) Sure, but the question is: once the syntax starts to get ugly for both because of changes we made to the language that make sense only on transformation and not on generation, would it still be the case? remember that the generation stage has a scripted population stage first, the transformation stage does not!... Not sure what you mean by scripted population stage. In both cases we need iterations, if statements and output/formatting expressions, anything more? Do you see anything missing in Daniel's proposal at http://wiki.apache.org/cocoon/AttributeTemplates ? I see stuff that we might not need (for loops maybe), but nothing missing IMHO. ... -oo- So, what's wrong with this? Where's the FS? The FS is in what I wrote above: it would be *nice* to have a *simple* language that was able to do both, but I've seen many people t
Re: happy "nikolaus"
Le 7 déc. 04, à 00:43, Torsten Curdt a écrit : ...we have auto-compiling javaflow!! Wow - thanks Torsten, looking forward to testing this! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
Le 6 déc. 04, à 15:57, Daniel Fagerstrom a écrit : ...What about being able to mix Groovy's XML sytax with the the ordinary one, wouldn't that be nice ;) (you just forgot to add the sound of Stefano's FS detector exploding in the background) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
Le 6 déc. 04, à 15:41, Glen Ezkovich a écrit :
On Dec 6, 2004, at 8:14 AM, Bertrand Delacretaz wrote:
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of
${xpath:}.
If nobody said this already (I have 150 or so mails to go ...), more
than one EL per template is clear FS to me. I'd be in favor of
specifying EL at the TemplateGenerator declaration time, and would
not go more granular than this...
+1, it might be good to have pluggable languages but run-time
switching is definitely FS - and confusing as well.
Thank you. Think this approach is applicable to the tag vs. attribute
debate?
Sure. Having mixed languages or mixed tag/attributes templating
mechanisms in the same template sounds equally confusing.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just say yes!)
Le 6 déc. 04, à 15:07, Vadim Gritsenko a écrit :
Reinhard Poetz wrote:
IIRC we aggreed that we like the current syntax of JXTemplate.
Exception: We deprecate the #{} notation in favour of ${xpath:}.
If nobody said this already (I have 150 or so mails to go ...), more
than one EL per template is clear FS to me. I'd be in favor of
specifying EL at the TemplateGenerator declaration time, and would not
go more granular than this...
+1, it might be good to have pluggable languages but run-time switching
is definitely FS - and confusing as well.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Le 6 déc. 04, à 10:10, Daniel Fagerstrom a écrit : ...BTW: I'm becoming more and more worried about the attribute template sytax that you used in your examples ;) I hope the syntax in my examples is so bad that people just dismiss it and focus on the rest of the story ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
Bertrand Delacretaz wrote:
...That's what I mean - having a transformer that can use the same
template syntax as used in the generator, so that the template
language can be used for both the generation and transformation
steps.
My FS detector is out of scale!!
Hmmm...maybe it needs a battery change after working too hard in the
last few days ;-)
Let me clarify with a concrete story: we start with a few beans passed
to sendPage, including a Collection of Person objects.
Alice writes a template for the XYZGenerator (our new attribute-based
template language), which receives the beans and generates an XML
document based on this template (syntax details are irrelevant for this
discussion):
${p/name}
${p/age}
At which point she gets an XML "data view" or "logical document" and
passes it downstream for publishing.
Then, Bob, who's in charge of the final presentation, writes another
template to convert this logical document to, say, "lightweight HTML",
for an embedded terminal (no CSS). This gets processed by the
XYZTransformer, which uses the same template and expression engines,
and the same syntax as the XYZGenerator (again, don't worry about
syntax details):
${page/title}
${p/name}
${p/age}
The XYZTransformer receives the XML produced by the XYZGenerator, reads
the above template from disk (or from the output of another pipeline),
and generates the HTML.
-oo-
Advantages:
A1) There's only one implementation of the template and expression
evaluation mechanisms.
A2) Bob can ask Alice for help with the templates, she knows them in
and out as that's what she's using as well.
A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
productive with the template language, which looks familiar. In a
pinch, he can ask the trainee to make minor changes in DreamWeaver, in
fact they saved a bunch by doing the prototype in this way.
A4) The XML logical document will "never" change once it's done, as it
contains all the data in presentation-independent format. Write it,
test it, forget about it. Alice doesn't want the critical parts of
their system to change too often.
A5) The XML logical document can be reused to publish the RSS feed, the
mobile WAP/WML version, the full-blown XHTML/CSS version, without
bothering Alice who's a busy and expensive person.
A6) Alice doesn't have to deal with the final customer who's always
asking for "just a small change in the page layout". She leaves this to
Bob for now, but they've considered training the customer to do this on
his own, the templates are simple and isolated enough that he couldn't
break anything anyway.
Disadvantages:
D1) The XYZTransformer is probably slower than a well-written XSLT
transform. But it's also much faster than the XSLT transform that Bob
tried to write. He's only been doing XSLT for four weeks and just plain
hates it.
D2) The XYZTransformer is a memory hog on large documents, as it loads
the document in memory so that the expression evaluator can process it
easily (AFAIK the current XSLT processors do the same in many cases,
however, so this might not really be a problem).
D3) Why so many steps? Generating XHTML directly could have saved some.
But it doesn't help for RSS or WAP/WML, and the generation is actually
much more complicated than what we see here, as configuration files and
site menu definitions need to be aggregated in the page, with different
variants depending on the final presentation target.
D4) Bob was initially confused about this generator/transformer thing,
why both? Alice told him not to worry, generators are not his business
anyway, he's only a Cocoon Transformer Template Designer (but a good
one after only four weeks here). He'll understand when he grows up ;-)
-oo-
So, what's wrong with this? Where's the FS?
I might be overlooking something but this could pave a much easier path
for people to jump into Cocoon and *stay*, not run away scared by XSLT.
XSLT is *the* stumbling block today, and IMHO we don't have a good
alternative to suggest. I don't mean to reinvent it, but as people are
working on improved templates anyway, this looks like a cheap but very
welcome addition.
-Bertrand, enjoying the debate...
smime.p7s
Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
(please ignore my previous message, hit send too soon ;-) Le 6 déc. 04, à 07:27, Bertrand Delacretaz a écrit : ... smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit : Bertrand Delacretaz wrote: Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. My FS detector is out of scale!! This is *exactly* what the XSLT WG did and failed miserably. XSLT can be used for both generation and tranformation. But it looks right for one (besides the stupid XML-ish syntax) and totally ackward for the other. XQuery is the same thing, only reversed: it can be used as a template language, and as a transformation language. If feels better for the first one (only ackward because, as usual, the XSLT WG starts with one name and ends up defining something else) and totally wrong for the second. Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR. Generation and transformation are two different things, done often by different people and for different goals and with different constaints. Having one language for both will do only harm, because it will make it harder for people to decide when to use generation and when to use transformation. -- Stefano. -- Bertrand Delacretaz independent consultant, Lausanne, Switzerland http://www.codeconsult.ch smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Le 4 déc. 04, à 22:11, Roy G. Biv a écrit : Aren't you really talking about just a transformer then?... ...Then the generator simply becomes a virtual one: A two for one! Only one codebase to maintain. Nothing to keep in sync. I see the idea, but I think the same thing can be done quite easily in code by reusing the same processing code in the generator and transformer. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit : On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote: ...Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. I'm not really sure what you mean by having something that could cover both steps. JXTG covers both steps in the sense that many people are using it to inject their data into their html. Now, to have a template transformer, that is something with which I would really like to play. I'm not very found of XSL. A simpler alternative could be a Really, Really Good Thing. That's what I mean - having a transformer that can use the same template syntax as used in the generator, so that the template language can be used for both the generation and transformation steps. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Le 4 déc. 04, à 19:24, Sylvain Wallez a écrit : ...Of course, this is related to our organisation where template writers have more a developer background. Right. And the problem now is that there is no simple way for people to move from "designer-friendly" environments to Cocoon-based publishing in small steps. They have to do a big jump, where many probably fall on their face ;-) ...The conclusion of this is that we must be careful of not overseparating concerns, as it may actually require more work without real architectural benefit... Agreed. OTOH your view is very html-centric IIUC. In situations where multi-channel output (web, mobile, print for example) is required, a two-step view brings many benefits. But you're right that in such case the first step is rarely pure XML, it's often biased towards the most common/preferred output format. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Le 4 déc. 04, à 18:56, Stefano Mazzocchi a écrit : Bertrand Delacretaz wrote: ...I think we need a) "data templates" (for a lack of a better word), to generate XML out of data (what JXTG does now), and b) "presentation templates" downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) I very much disagree with this. The notion of separating a data template from a presentation template is arbitrary and nothing really generally useful from a SoC point of view. I didn't mean two different *template mechanisms*, rather that we need templates at two (or several) points in a pipeline, not only at the beginning of the pipeline as the G in JXTG implies. Thinking about it, what I was talking about is two *use cases* for the templating system, with very different point of views and users skills. ...What we need is a template language. Period. Something that converts data *structures* into SAX events. Whether you use it for data or presentation or whatever else, it's up to you... Fully agreed. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs
Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit : ...I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must... I'd say keeping JXTG alive is a must, and refactoring is probably needed to make this happen. OTOH what's been discussed in the last days regarding attribute-based Dreamweaver-friendly templating looks to me like a very welcome evolution, which can happen in parallel. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Le 4 déc. 04, à 14:14, Daniel Fagerstrom a écrit : Bertrand Delacretaz wrote: ...b) "presentation templates" downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) ...For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves b) would be nice but it is quite complicated to implement in an efficient way. One can of course stream the transformer input to a DOM tree that is made available in the context object and then let a JXTG like script work on that. But the question is if we would be happy wih the performance... It's hard to say without trying it, but IIUC we can essentially get this (i.e. reuse the data-to-XML templating mechanism for downstream transformations) for free, if taken into acount in the design. Just a simple stream-to-DOM implementation would allow people to experiment. And it might make a big difference, from the users point of view, by making it possible to use a single tool for the whole presentation pipeline, and making presentation templates way easier than raw XSLT, which is a major stumbling block for many people. We might want to make it work first, to see how much people like it. If they like it, I'm sure someone will find a way to make it fast, if needed. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0 (Just my opinion)
Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit : ...I'm not sure I agree that templates as being part of the view. I look at them more as providing XML structure to the data We need both actually - if you work with the "two-step view" pattern (which is very natural with Cocoon), you need a first set of templates to generate XML out of your data, and a second set to transform the XML into the final presentation format. Currently we have JXTG for the first step, and mostly XSLT for the second. Having something that could cover both steps and be usable by either programmers working on the first step or designers working on the second would be a Really Good Thing. -Bertrand [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Le 3 déc. 04, à 22:35, Christian Stocker a écrit : On 3.12.2004 21:50 Uhr, Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib > > That's pretty much all you have to do to make me happy. Maybe Zope's TAL idea is something for you. http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL They are very fond of the fact that it's "Dreamweaver-Compatible" I think we need a) "data templates" (for a lack of a better word), to generate XML out of data (what JXTG does now), and b) "presentation templates" downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) - oo - For a), JXTG does a good job currently, but having a single mechanism for both would make a big difference in the number of things that people have to learn to be productive with Cocoon. For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is "simple enough" for such people to grasp. - oo - To me, TAL's design looks simple for simple things, yet powerful and extensible. Looks like an example to follow, maybe even like a spec to adopt instead of reinventing it.. ...I once started implementing that in my own framework (a php based cocoon ripoff ;) ah good. sometimes people ask what popoon is, now we know how to describe it ;-) ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Proposal] review of sitemap component documentation
Le 24 nov. 04, à 08:48, David Crossley a écrit : ...That is why i was asking if anyone was going to say: stop, we need to throw away or redesign that excellent SitemapTask to cope with separate bloack docs Just one small thing: the name SitemapTask says little about what this does, as I understand you're working on it, it might be good to rename it to something more meaningful. SitemapComponentDocTask maybe. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: review of sitemap component documentation
Le 2 déc. 04, à 10:36, David Crossley a écrit : ...I do want to use tools to help process the xml table. For example, i have a 'sed' script to add a blank column. Should i commit those somewhere?.. Yes, somewhere in the tools directory would be good IMHO And/or a single bugzilla issue to keep track of the work done on this table might be good? Not sure what you mean there. I was expecting that just the svn commit log messages would suffice. Just having an issue page show up in the bugzilla list would help remind us that there is work to be done there, and keeping a single-page history of what we do might be good. But you're right that the svn log might be enough. ...Did you document the process already, i.e. how do new entries come into the table when someone adds a new component? (I have not reread the whole thread so I might be missing something obvious, please bear with me). My inial goal was to set up a functional table manually, then work on ways to automate its population and ways to ensure that it stays synchronised... Even having a way (script, ant task, whatever) to *check* what might be missing in the table would be enough I think, population is no big deal but finding out what's missing is harder I think. ...Let us take it steadily. It is a long road. sure! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: review of sitemap component documentation
Le 2 déc. 04, à 04:32, David Crossley a écrit : Okay the initial coordination table is now ready. http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html big big thanks for making this happen, it is an important step I think. Hope to find time to help here. Maybe a periodic nag email to here with the number of unreviewed entries would be good? And/or a single bugzilla issue to keep track of the work done on this table might be good? Did you document the process already, i.e. how do new entries come into the table when someone adds a new component? (I have not reread the whole thread so I might be missing something obvious, please bear with me). -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Design] JXTG 2.0
Le 26 nov. 04, à 21:24, Jonas Ekstedt a écrit : ...* Do you have any pointers on load testing? I tried JMeter but couldn't get it to work, are there any alternatives you could recommend? I.. Either wget [1] or ab [2] can be very useful for simple performance testing. Running several instances of ab in parallel can give you meaningful figures in a very simple way - but you'll have to find out if your pages are cached or not (maybe switch to noncaching pipelines to be sure) to know what you're measuring. -Bertrand [1] http://www.gnu.org/software/wget/wget.html [2] http://httpd.apache.org/docs-2.0/programs/ab.html smime.p7s Description: S/MIME cryptographic signature
Re: committers page
Le 25 nov. 04, à 08:18, Ralph Goers a écrit : ...Does this mean the list contains all past and present committers? AFAIK yes, did you spot people missing from the list? -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Proposal] review of sitemap component documentation
Le 24 nov. 04, à 13:49, [EMAIL PROTECTED] a écrit : ...If you do it in xdoc, beware that you will end up the administrator of the table (integrating commits from non-committers)... FYI I volunteer to help maintaining this file based on info provided by non-commiters, so that David does not have to be the only administrator of this. I don't have a lot of time available these days, but this I can do. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Client side validation
Le 24 nov. 04, à 12:42, Guido Casper a écrit : Bertrand Delacretaz wrote: Le 23 nov. 04, à 10:53, oceatoon a écrit : ...Is different JS really coded for different browsers? I thought there were only those with JS and those without, in the second case validation would go back to Server Side but no different version of scripts... your (future) client might *not* even be a browser per se. Think Flash, XUL, and related stuff. This may be a little off topic and I'm asking out of curiosity what others think. But I wonder if flow (and continuations in particular) and cforms really is an appropriate technology for "rich" (and potentially stateful) clients? It's hard to say without having a concrete example to judge, and I have none at this time ;-) My point was that saying "client-side validation will always be done in javascript" sounds a bit too restrictive, I' d rather say "although client-side validation will be done in javascript in 95% of the cases, we allow other options even if javascript is the standard." -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Proposal] review of sitemap component documentation
Le 24 nov. 04, à 07:45, David Crossley a écrit : ...If no-one says stop, then i will just commence soon. so...I'm not saying stop ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Planning Cocoon's future
Le 23 nov. 04, à 16:42, Reinhard Poetz a écrit : ...So if you (vadim, betrand, sylvain) tell me that we should wait for a working replacement I don't have a problem to drop this point... +1 Actually we might need to invent a new status for XSP: it's not deprecated, we don't recommend using it and we're not looking to develop it any further. But we recognize it's important for some users, and as such are in no hurry to kill it. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Taglib Block, and Re: Planning Cocoon's future
Le 23 nov. 04, à 14:54, Vadim Gritsenko a écrit : ...ATM, I'm -1 on deprecating XSP. There is just not enough information yet to make such a decision - we have some wishes but nothing concrete yet... I'm +1 on your -1 ;-) XSP is used in a lot of existing apps, it works and it doesn't seem to be a heavy burden to carry. I don't think there's a real urgency to deprecate XSP, except the desire to move forward of course. But not developing it any further is clear signal already. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Client side validation
Le 23 nov. 04, à 10:53, oceatoon a écrit : ...Is different JS really coded for different browsers? I thought there were only those with JS and those without, in the second case validation would go back to Server Side but no different version of scripts... your (future) client might *not* even be a browser per se. Think Flash, XUL, and related stuff. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Release and updating the website
Le 23 nov. 04, à 06:42, David Crossley a écrit : David Crossley wrote: Upayavira wrote: Also, when I did run Forrest, I really had to dig to find the generated pages, whereas I would have expected them to have been generated "in place", i.e. into the place from which I'd commit them directly to SVN... I'm with David here (i.e. generating in build/site as now) - if you generate directly into the final tree I think it's much harder to find out which files must be *deleted* from the final destination. Generating somewhere else allows you to compare lists of files to find out what must be removed, e.g. find /final-site-dir -type f | sort > /tmp/f1 find /generated-stuff -type f | sort > /tmp/f2 diff /tmp/f1 /tmp/f2 Of course there are other ways, but I think this is practical. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Client side validation
Le 22 nov. 04, à 23:44, Sylvain Wallez a écrit : ...So the idea now is that a validator produces an XML representation of itself, which could be a simple as it's definition translated to the "fi:" namespace ...It's then the job of the presentation XSLs to transform into something useful. Only those validators where a client-side implementation is possible would produce an XML fragment in the element. I like the idea, +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Fwd: Saab uses Cocoon
FYI, here's a good catch from Gregor: De: "Gregor J. Rothfuss" <[EMAIL PROTECTED]> Date: 23 novembre 2004 02:34:52 GMT+01:00 À: [EMAIL PROTECTED] Objet: Saab uses Cocoon i didnt know, because it was before my time: http://www.saab.com/index.xml seems to still run on cocoon 1.8 :) -- Gregor J. Rothfuss COO, Wyona Content Management Solutionshttp://wyona.com Apache Lenya http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: site update - please review
Le 21 nov. 04, à 09:43, Upayavira a écrit : ...I've just run Forrest and have uploaded the site to: http://www.apache.org/~upayavira/site/.. I have a looked at a few pages that I know, everything looks ok to me. Thanks for this! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: generating the docs with Forrest
Le 21 nov. 04, à 02:14, David Crossley a écrit : ...So keep using Forrest-0.5.1 which worked the last time that i rebuilt the website... ok. ...Also tried with forrest 0.5.1, no success either (tried "forrest" not "build site"). Isn't it 'build docs'? The Cocoon build system generates some additional source docs, then it calls forrest. Did you set the FORREST_HOME environment variable... Ok, it might have worked with forrest 0.5.1, but I got sidetracked to 0.6 thinking that we had to use the latest Forrest. Hopefully Upayavira or someone can update the wiki instructions page, I won't have time to help more today or tomorrow. -Bertrand smime.p7s Description: S/MIME cryptographic signature
generating the docs with Forrest (was: Release and updating the website)
Le 19 nov. 04, à 19:49, Upayavira a écrit : http://wiki.apache.org/cocoon/CocoonWebsiteUpdate ... I'll do that too, if I can get Forrest to work. Unfortunately the above link doesn't entirely make sense. FYI I have tried the following, no success at this point. But I haven't done this in a looong time. 1) get forrest 0.6 binary, configure as indicated in readme 2) cd BRANCH_2_1_X, build clean 3) run forrest from same directory I get this message Cannot find CatalogManager.properties And a few seconds later this error which stops forrest. X [0] linkmap.html BROKEN: /home/bert/workspace/apache/cocoon-2.2/BRANCH_2_1_X/src/documentation/ skins/pelt/xslt/html/site2xhtml.xsl (No such file or directory) Also tried with forrest 0.5.1, no success either (tried "forrest" not "build site"). Note that our forrest-related configs apparently need to be updated for forrest 0.6, dunno if it's been done yet (http://forrest.apache.org/docs/upgrading_06.html). Gotta run to other stuff now, won't have more time for this today. -Bertrand smime.p7s Description: S/MIME cryptographic signature
portal block build broken (missing FullScreenMapping class)
Looks like this class is missing, did someone forget to commit it? src/blocks/portal/java/org/apache/cocoon/portal/acting/ BookmarkAction.java:45: cannot resolve symbol symbol : class FullScreenMapping location: package helpers import org.apache.cocoon.portal.acting.helpers.FullScreenMapping; -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Release and updating the website
Le 19 nov. 04, Ã 17:23, [EMAIL PROTECTED] a Ãcrit : On Fri, 19 Nov 2004, Bertrand Delacretaz wrote: Le 19 nov. 04, Î 16:05, Upayavira a Îcrit : ...Thus, the site needs to be regenerated with Forrest, which, to date, I haven't done. You probably know this already: there are instructions at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate the site is not moved to SVN? here the instructions are talking about CVS? You're right, it's svn instead of cvs now. We need to update that page. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Release and updating the website
Le 19 nov. 04, à 16:05, Upayavira a écrit : ...Thus, the site needs to be regenerated with Forrest, which, to date, I haven't done. You probably know this already: there are instructions at http://wiki.apache.org/cocoon/CocoonWebsiteUpdate I might try it tomorrow if you don't beat me to it, not sure if I'll find time though. I'll indicate here if I get to doing it. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [ANN] Apache Cocoon 2.1.6 Released
Le 19 nov. 04, à 13:25, Carsten Ziegeler a écrit : Apache Cocoon 2.1.6 Released Congratulations to all and big thanks to you, Carsten! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: question about jar conflicts/java class loading conflicts
Le 18 nov. 04, à 18:34, Eric Bloch a écrit : ...ps... our project is described at http://openlaszlo.org Great to see you here! I'm probably not the only one to think that a Laszlo frontend to a Cocoon backend would be a match made in heaven for many kinds of applications... -Bertrand. only half-dreaming ;-) smime.p7s Description: S/MIME cryptographic signature
webdav-step3 test fails with caching pipeline (was: [VOTE] Release of 2.1.6)
Le 18 nov. 04, à 10:45, Guido Casper a écrit : I've tried it but it didn't help. Setting the pipeline in step3/sitemap.xmap to noncaching did help - the webdav-step3 test passes every time now on my macosx / JDK 1.4.2 setup. Hmm... Without this change, If I run the test several times, I sometimes get no errors, and sometimes one of the ones below, or both: [foreach] webdav-step3.xml:44: Running test [XPath: select /html/body/form/p/[EMAIL PROTECTED]'title']/@value, pattern Content B] Failure: file:/Users/bert/workspace/apache/cocoon-2.2/BRANCH_2_1_X/build/cocoon -2.1.6-dev/test/anteater/webdav-step3.xml:44: XPath /html/body/form/p/[EMAIL PROTECTED]'title']/@value: expected pattern 'Content B', got 'Title changed by anteater step3 test'. [foreach] webdav-step3.xml:93: Running test [XPath: select /html/body/form/p/[EMAIL PROTECTED]'title']/@value, pattern Content B] Failure: file:/Users/bert/workspace/apache/cocoon-2.2/BRANCH_2_1_X/build/cocoon -2.1.6-dev/test/anteater/webdav-step3.xml:93: XPath /html/body/form/p/[EMAIL PROTECTED]'title']/@value: expected pattern 'Content B', got 'Title changed by anteater step3 test'. And sometimes the whole webdav-step3 test passes. I've also tried adding ?dummy=1 with different values at the end of each contentB.xml URL (to try to prevent caching) but it didn't help either. But with the noncaching pipeline all is well. If someone has time to investigate deeper... -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release of 2.1.6
Le 18 nov. 04, à 18:43, Sylvain Wallez a écrit : ...It would be good for next releases to explicitely ask for people to send test feedback indicating the platform/jdk version on which they ran the test. That would give an idea of how much people actually did the test... In the "ideas are cheap, implementation is expensive" department: I had the idea of creating a bunch of bugzilla issues for the tests that must be done prior to a release. In this way people could comment on which tests they ran, on which platform, etc. Or a wiki page, whatever works. Creating a list of things to test, where people can put a mark for tests that they have run, could be a big plus. But...didn't find the time either. Hopefully next time ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release of 2.1.6
Le 18 nov. 04, à 00:43, Ugo Cei a écrit : hmm.. are you testing on macosx and seeing this sometimes only? No, on Linux. And it seems to be repeatable. You're right, sorry. I see the same here on macosx ad webdav-step3.xml:93. And FWIW the test that fails only sometimes here (seems related to the timing of reloading the changed sitemap) is that one: [foreach] flowscriptReload.xml:69: Running test [XPath: select html/body/p[1], pattern .*replaceme-123.*] Failure: file:/Users/bert/workspace/apache/cocoon-2.2/BRANCH_2_1_X/build/cocoon -2.1.6-dev/test/anteater/flowscriptReload.xml:69: XPath html/body/p[1]: expected pattern '.*replaceme-123.*', got 'replaceme-abc'. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Supersonic Tour: Bean editor application error.
Le 18 nov. 04, à 00:07, Upayavira a écrit : Well spotted. These variables in flowscript must be prefixed with var. This is a recent change. Can you handle this? it's done already ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release of 2.1.6
Le 17 nov. 04, à 22:40, Ugo Cei a écrit : ...Do we still have an anteater test failing? It would be nice to fix it, but since this doesn't seem to bother anyone, here's my +1. I don't really know about the implications of the failing test (i.e. would it not break existing apps in some cases?) (details at http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=25121) but if you guys think it's ok then here's my +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Supersonic Tour: Bean editor application error.
Le 17 nov. 04, à 21:56, Ralph Goers a écrit : at query_allTasks (file:/home/rago2483/cocoon/head/BRANCH_2_1_X/build/webapp/samples/ blocks/tour/bean-editor/cocoon-app/flow/tour.js, Line 27): Implicit declaration of global variable 'list' forbidden. Please ensure all variables are explicitely declared with the 'var' keyword Also fixed, thanks for testing! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Supersonic Tour: multi-page form error.
Le 17 nov. 04, à 21:53, Ralph Goers a écrit : ...at public_startMultiPage (file:/home/rago2483/cocoon/head/BRANCH_2_1_X/build/webapp/samples/ blocks/tour/flow/multi-page/multi-page.js, Line 36): Implicit declaration of global variable 'page' forbidden. Please ensure all variables are explicitely declared with the 'var' keyword.. Fixed, thanks! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Release of 2.1.6
Le 17 nov. 04, à 23:51, Ugo Cei a écrit : ...Actually we have two anteater tests failing: the second one does not appear unless you set anteater.option.haltonerror = false in local.build.properties. Would it be possible to set it when running the automated tests? Anyway, here's the failure: [foreach] webdav-step3.xml:93: Running test [XPath: select /html/body/form/p/[EMAIL PROTECTED]'title']/@value, pattern Content B] Failure: file:/home/ugo/workspace/cocoon-2.1/build/cocoon-2.1.6-dev/test/ anteater/webdav-step3.xml:93: XPath /html/body/form/p/[EMAIL PROTECTED]'title']/@value: expected pattern 'Content B', got 'Title changed by anteater step3 test'. [foreach] ... done (12ms) [foreach] webdav-step3.xml:91: Finished http://localhost:///samples/blocks/webdav/step3/repo/dir2/ contentB.xml (17ms).. hmm.. are you testing on macosx and seeing this sometimes only? I've seen such things on macosx sometimes, not sure if it's this same test but I've had some anteater tests fail sometimes, and pass if running the tests again shortly after. It looked like a weird timing problem, didn't investigate further. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [ERROR] CVS commit to cocoon 2.0
Le 16 nov. 04, à 03:36, Antonio Gallardo a écrit : I was trying to update the ASF bugzilla links in cocoon-2.0. I have no commit access there. It is closed? ... It has been set readonly AFAIK How I can update the links? am I using the wrong repo? The links to the old bugzilla should be mapped to the new one on the ASF servers, with rewrites or something IMHO (as there are zillions of them in the wild), check with infrastructure@ if needed. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon-2.1.X Tests Failure 11/12/04
Le 12 nov. 04, à 14:51, Vadim Gritsenko a écrit : Automated Cocoon Unit tests failed! ... [foreach] reader-mime-type.xml:74: Running test [Header: Content-type = text/html[1;31m Failure: file:/disk/raid0/home/vadim/svn/cocoon-2.1.X/build/cocoon-2.1.6-dev/ test/anteater/reader-mime-type.xml:74: message doesn't match because header 'content-type' is not present[m I have reopened http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25121 which is about this. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Vote] Remove woody and portal-fw in 2.2?
Le 10 nov. 04, à 17:09, Ralph Goers a écrit : I'm +1 for removing woody and portal-fw from 2.2. +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Introduction
Le 10 nov. 04, à 01:22, Leszek Gawron a écrit : ...I am really honoured to be a part of community being so appreciated by users. Thanks for your words Leszek! We're joking about people being old or young but that's how we are anyway, it doesn't matter much ;-) And what you're doing sounds exciting - great to have you onboard! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Introduction
Le 9 nov. 04, à 10:16, Sylvain Wallez a écrit : Wow, 1977... Cool! -Bertrand, 42 years young committer ;-) smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Remove FlowScript Function Parameters Support
Le 9 nov. 04, à 14:38, Vadim Gritsenko a écrit : ...Proposed phase out plan is: 1. Write ERROR into the log file in 2.1.6 when usage of deprecated syntax is detected. 2. Throw exception in 2.1.7 when usage of deprecated syntax is detected. 3. Completely remove support of deprecated syntax in 2.2. +1 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Introduction
Hi Ralph, Thanks for your introduction and once again welcome - it is great to see people with widely different use cases, environments and backgrounds here! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [GT2004] I've put my presentation online, could others do the same?
Le 6 nov. 04, à 18:57, Ugo Cei a écrit : ...I'll certainly do it ... as soon as you do a chmod g+w on that directory. oops sorry ;-) Should be ok now. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Apache account request: Ralph Goers
Le 6 nov. 04, à 17:41, Ralph Goers a écrit : ...I just tried to fax Sam but all I get is his message machine. My fax cannot connect. This is from infrastructure@ earlier today, you might want to use Dirk-Willem's fax: Le 6 nov. 04, à 14:17, Dirk-Willem van Gulik wrote: Note that the ASF Secretary is out of the office until monday; if this is urgent you can send the fax to any other officer of the ASF too (feel free to use +31715146045) and get him or her to acknowledge it (and still send make sure that a copy by snail mail or fax gets to the ASF Secretary of course). -Bertrand smime.p7s Description: S/MIME cryptographic signature
[GT2004] I've put my presentation online, could others do the same?
I have put my presentation files in /www/www.apache.org/dist/cocoon/events/gt2004/presentations on cvs.apache.org so that they can be found (once mirrors are updated) at http://cocoon.apache.org/mirror.cgi. Could other speakers do the same (unless Steven or someone from the team has them all in one place and could copy them there?). GT speakers who don't have access to this machine are welcome to give me a download URL for their files and I'll put them there - it would be good to have all the material in one place. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: FirstFriday
Le 4 nov. 04, à 14:24, Ugo Cei a écrit : Tomorrow is FirstFiday ([1]), isn't it? Regardless of what you're doing tomorrow, I would like to invite all committers and interested users to hang around on the IRC channel , which should be more popular, IMHO. One of the nice things about IRC is that you can join and just lurk without being too distracted. Personally, I'll be there even if I won't probably be very active until late in the evening (CET). Thanks Ugo - I'll be teaching in the morning and I'm not supposed to be on IRC simultaneously... But you're right, hanging around and participating in the occasional discussion allows often interesting discussions to happen (and fun ones sometimes, it'll be Friday after all ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Switching rhino implementation
Le 1 nov. 04, à 19:28, Reinhard Poetz a écrit : ...I would wait with switching to the new flowscript implementation until the release of 2.1.6 Then we have a few months to test it in branch and trunk and if everything goes well I would deprecate the old one and rename it to "javascript-legacy" and the new impl should be the default language In 2.2 I would remove the old implementation completly... +1, there's no hurry I think, better switch after the release to test the new implementation a bit more. Except maybe using "javascript-2.1.6" instead of "javascript-legacy", in order to avoid "javascript-legacy-square" if there is another such move down the road ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Templating Engine - Next steps?
Le 1 nov. 04, à 17:30, Reinhard Poetz a écrit :
After a lot of mails talking about expression languages and templating
enginges I try to summarize the current state of our discussion. I
see following requirements so far (in brackets you find the name of
the person that brought up the requirement):..
Just to be clear: we're talking about the templating language used to
generate XML out of (usually flowscript) data, right?
I'm asking (although I know ;-) because the requirements of a *final
presentation" templating system might be fairly different - at present
the mainstream way (AFAIK) is to use XSLT to generate HTML, WML or
whatever, but for many people "templating" in the context of a webapp
means roughly "edit pages with DreamWeaver, put some special codes and
let the templating engine insert the data".
Maybe we should call JXTemplate our "XML templating engine" to avoid
any confusion.
...So, how do we continue to meet all these requirements?
A.) Rewrite/refactor JXTemplate
- break it up in smaller, easier understandable/maintainable
pieces
- deprecate #{} syntax and make expression languages plugable as
Sylvain suggested
- investigate the performance problems (I guess there are only
problems if macros are used)
- add the missing things from above...
Sounds good if people are willing to do it.
Don't know enough about the other options, but I like this idea:
...In my opinion we should write JXTemplate 2.0 which would be from
the user's POV as similar as possible to 1.0.
Technically this could be a complete rewrite (use garbage, tempo or
really from scratch) or at least a major refactoring...
It would be (of course) good to include automated tests as well, using
anteater for example, as this is a critical component
Calling it JXTemplate is better for marketing reasons because it shows
more stability than telling our user base that they should use
something completly different in the future. Calling it differently
gives another impression than incrementing version numbers.
+1
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: rev 56219 - cocoon/site/site
Le 1 nov. 04, à 12:16, David Crossley a écrit : Yes it is generated by Forrest. However, this is a good idea just to do a quick edit. Probably no-one will update the source in the next two weeks... Thanks for the clarification! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 17:20, Vadim Gritsenko a écrit :
..But we were talking about getChild("foo")...
got it now - thanks ;-)
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit : Vadim Gritsenko wrote: Bertrand Delacretaz wrote: ... And technically in plain XPath it would be something like //widget/foo/@bar IIUC, JXPath has pluggable introspectors, so it above can be reduced to: $widget/foo/@bar Eeek. Do you really think people will write their introspectors to have a readable syntax? I'm a bit lost here (ok it's Friday ;-) JXPath *does* actually do stuff like $bean/member/submember, right? And according to its docs [1] it should also allow $bean/member/@submember and return the same result. So, I don't see what we're talking about really - I must be missing something obviously ;-) -Bertrand [1] http://jakarta.apache.org/commons/jxpath/users-guide.html#Attributes smime.p7s Description: S/MIME cryptographic signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write something
like "widget.getChild("foo").getAttribute("bar")" in XPath?
Tecnically, this will be
getAttribute(getChild($widget, "foo"), "bar")
in JXPath. Not exactly easy to read, but possible :)
And technically in plain XPath it would be something like
//widget/foo/@bar
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
Le 29 oct. 04, à 14:36, Jeremy Quinn a écrit : ...I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) Although...implementing persistence based on ORO might be an interesting exercise for a Friday afternoon ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] StringTemplate: The answer to our templating needs?
Le 29 oct. 04, à 12:59, Reinhard Poetz a écrit : Bart Molenkamp wrote: ... No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. The question is: Do we want to prevent our users from this or is it their own decision? Definitely their own decision. I think the "show the mainstream/correct way but don't block users from doing whatever if they really want" attitude that we see in several places in Cocoon is very powerful. It leaves space for people to be experimental and (sometimes) find cool new ways of doing things. If you think about it this is the basic philosophy of unix: consider your users as intelligent people and don't take them by the hand too much. This is very powerful for platforms, and Cocoon *is* becoming a platform. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
Le 29 oct. 04, à 12:41, Jeremy Quinn a écrit : ...What I hope to do is to make the Queries persistable in HSQLDB via ORO... ORO? That's a regexp package, do you mean OJB instead? ...I suppose one of the first questions that needs asking before going ahead and making an Apache ORO equivalent to the above, is : is the structure of the SimpleLuceneQuery/SimpleLuceneQueryBean and SimpleLuceneCriterion/SimpleLuceneCriterionBean as good as it needs to be? Can it be improved? Is it easy enough to extend it? Is the Interface overkill? If it is desirable, is it properly done etc. etc... One simplification in terms of storage might be to edit the query criterion as an XML document and store this as a block in the DB (but I don't know how hard it is to get from this XML to Lucene criteria then). It would make the DB model much simpler, and I don't think you're running queries on the criterion table anyway, or are you? I imagine querying on the user_id, date and name fields only, so I'm not sure if the separate criterion table brings something. Also, considering storage of an XML block keyed by user_id, date and name makes it easier to make storage pluggable, allowing file-based storage if someone wants it for example. I don't want to suggest change for the sake of change, but as you're asking ;-) ...Should QueryFavourites.js be rewritten in Java? Should it be in the style of a DAO? Dunno about a DAO but it looks like it should - this is not code that is going to change often, and it needs to be robust and tested, so I'd move it to java. ...I guess I need to add a new Block to Cocoon, eek I have never done one !! It's very easy if you take one of the simplest blocks as a template. ...Once again, I would like to express my thanks to Antonio for offering to help with this... We know he's a nice guy ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] StringTemplate: The answer to our templating needs?
Le 29 oct. 04, à 10:17, Carsten Ziegeler a écrit : ...Hmm, one of the things I really don't like with JXTG is that you have to different expression languages. You never know which to use and some things work only with one specific language. And for me this comes near to FS :) Yes - but pluggability can be useful for the future and have good effects on code: if someone finds time to refactor the (working but verrry scary if you ask me) JXTG code, making the expression language pluggable certainly helps improve the code structure. I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. ...So, let's decide on one language that we think is the best, but let's provide a hook so others can plugin their language if *they* want to... +1 to both -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Leszek Gawron and Ralph Goers as committers
Le 28 oct. 04, à 17:04, Torsten Curdt a écrit : Folks please cast your votes for: [+1] Leszek [+1] Ralph Welcome Leszek and Ralph, and big thanks for your involvement in the last (...insert long period of time here...). Keep it up! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Locking the JS global scope to avoid implicit declarations
Le 28 oct. 04, à 14:49, Sylvain Wallez a écrit : ...I implemented this feature locally and it works beautifully. I firmly believe this should be the default as it prevents weird errors that can be very confusing... So do I - I did sweat a bit on this a few weeks ago, it is a common mistake that is not easy to spot without debugging. The question is: do we want this to be configurable? Are there some valid use cases where one would like to create global variables that weren't previously declared. I can't find some. I can't see any use cases that would require configuration either. OTOH, if it's cheap to make it configurable, why not. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Locking the JS global scope to avoid implicit declarations
Le 28 oct. 04, à 14:56, Carsten Ziegeler a écrit : This might be a dump question, but I thought that global variables are attached to the session of the current user. Is this wrong or are there different kinds of global variables? I think what Sylvain is referring to is the unwilling creation of global variables in flowscript, when one forgets the "var" keyword. I had this problem a while ago, see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109493633700571&w=2 -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Upgrade HSQLDB to 1.7.2 in 2.1.6-dev
Le 28 oct. 04, à 09:32, Ugo Cei a écrit : ...In this sense, "less is more" and I'd be probably be -1 on switching to Derby, on account of the fact that, by bundling a full-fetaured RDBMS, we will probably give the impression that we somehow endorse it as the recommended solution... I basically agree but this needs to be balanced with promoting good ASF stuff. Basing our samples on ASF libraries and tools helps promote them. Me, I'd be +1 if someone wanted to switch to Derby for the DB samples, assuming this person does the work (as there is nothing to fix in regarding the HSQLDB samples AFAIK). ..Then people will starting asking suppport questions relevant to Derby on the users' list and so on... We'd just tell them to go ask on Derby's lists, which might bring more users to them. Don't get me wrong, I agree that less is more and that our samples must stay samples - but if we can base them on ASF stuff, all the better. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Upgrade HSQLDB to 1.7.2 in 2.1.6-dev
Le 28 oct. 04, à 01:39, Antonio Gallardo a écrit : ...Question: In Cocoon 2.1.6-dev: Upgrade HSQLDB to version 1.7.2? ... [X ] I don't care. or rather trust you to upgrade it the corresponding samples still work after the upgrade. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
...So we would have two separate instances of Cocoon (or Forrest). One is the staging server, which is the head. The other is the live site, which uses the "current-docs" tag... Not necessarily two instances, could be one IMHO, with URLs selecting either the relased docs or other tags (and prominent markers on the page when viewing an unreleased revision). ...I do see some issues with this proposal. When one edits a single document, they can click and view, and will be able to see any structural and content problems. When one edits a heap of documents, then would need to click on each doc to see if it works... Yes. Could use a validation/crawler script though. ...Broken internal links are not apparent by just looking... Also true, and here also a validation/crawler mechanism could help. ...Does SVN enable us to "move" tags? If not, then this proposal might fail. We could not have a new tag for every little documentation tweak hmm...if moving tags is not practical we could always do the opposite, have a dynamic configuration parameter indicating which revision is the currently published one. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 23:36, Helma van der Linden a écrit : ...G4. Make submitting documentation a more straight forward process. I haven't yet looked at the ins and outs of the xdocs, but I know from the times I tried to find the documentation in the checked out tree that I was unable to figure out how it worked... Sure. If committers can quickly see online the results of a small patch to the docs (which my proposal allows), it will be much easier and motivating to apply such patches. Direct applying of patches by authorized users is another story, but this is a first step. ...However, we should also think about how to get the quality of the documentation updated and how to encourage potential documentation writers to actually sit down and produce the actual text... On one hand I think much actual good text is here already, just buried too deep and not used enough to trigger the right itches to scratch. Also, I think the overall felling for many of us currently is "the docs suck anyway so why bother" - I'm simplifying a bit, but until we're somewhat proud of our docs it might be harder to get the work going. Many thanks for your work towards this, it is really appreciated, but as you notice it's only very few people in our community who currently care enough about our docs to actually do something. So I think implementing what I'm suggesting could help. Sorry that this is yet another discussions on docs tools without concrete actions, but as I said in my proposal the benefits seem big compared to the investement, so I think it is worth discussing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 22:56, Frédéric Glorieux a écrit : ...T2. Build an index with Lucene, triggered via SVN post-commit hooks, uses a live Cocoon instance to generate an easy to index XML document for Lucene. Include metadata fields as mentioned in G2 above, generated from (enhanced as compared to now) document content I'm working on that (nto enough), it seems to me only a consequence of upper.,,, Great! So we might be able to use your stuff IIRC. ...For delete, a hook from SVN is needed. Right, gotta check if SVN provides this. ...T5. Put mod_cache in front to minimize server load (HTTP POST can be used to invalidate pages if quick updates are needed to check edits). You give me the trick for something that I was asking to Sylvain, a kind of pure cocoon mod_cache with http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109636070505876&w=2 Why pure Cocoon? mod_cache works so well. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 22:34, Upayavira a écrit : ...So you'd use HEAD or whatever to view the latest commit, and the public would see the "current-docs" tag. That could work. But would we want the HEAD to be password protected, or in some way hidden so that it doesn't get regularly viewed when it isn't live yet?... I'd just add a notice to pages when one's not viewing the released version. No need for any secrets or passwords IMHO. So, when do you start?.. That's the problem - I'd like to say "right now" but I have to keep my business going at the same time. - Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 21:56, Jorg Heymans a écrit :
...1)Does all this actually make the documentation any better?
The content, would not immediately be improved of course. But
simplifying the docs publishing process is an enabler for improving the
docs.
2)Should any effort towards documentation ATM go into improving its
*quality* or improving its
{searchability|updateability|scaleability|auto-generateability}
Both, but many of us agree that the biggest problem now is
accessibility (both from the user's and from the writer's point of
views) of the docs.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 21:23, Scherler, Thorsten a écrit : To understand it right you do not want online editing, workflow,... right? Why not, but separating this concern from the publishing process makes the problem easier to tackle IMHO. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] doco lite?
Le 26 oct. 04, à 21:20, Upayavira a écrit : ...The thing you seem to have missed is the staging process. If I have written an xdoc, I want to see that as HTML, on a staging server, before I actually publish it. After all, the XML might not even be valid, or there might be mistakes. I need to be able to see the page on the site before I publish it... How about using SVN tags for this? -Current known good version of the docs is always tagged as "current-docs" -Website serves this tagged version on the public site -New docs releases are done by moving this tag to the appropriate revision (I didn't try moving tags in SVN yet but it shouldn't be a problem) Then you'd use the current release for the staging process, and update the public version by moving the SVN tag. -Bertrand smime.p7s Description: S/MIME cryptographic signature
