Leo, > Marc, > > this clarified a lot. Basically I was worried about how to express > 'ordering' of content, and it is only now I get that your idea here is > to express the ordering by having a filename specification. > or by having xpath lookups ;-) (the or is exclusive at your own coice)
in every case ordering based on xpath would be mostly not a good idea better use : - labeling: getting the caption for the menu from the file itself (more expressive then the filename often: eg for faq the full question) - filtering based on e.g. an attribute value priority="high" etc etc (you'll even start to love xpath when we're done :-)) > Just looking at the main avalon page: > > About > Overview > Features > Getting Started > Download Binaries > Download Source > Case Studies > License > Contributors > Sub-Projects > Framework > Excalibur > Phoenix > Cornerstone > Applications > LogKit > Guides > Avalon for Beginners > Developing with Avalon > Developing with Phoenix > Developing with Logkit > For Developers > Coding standards > CVS > Mailing Lists > > you'd express this as > > about/ > 1.Overview.xml > 2.Features.xml > 3.Getting-Started.xml > 4.Download-Binaries.xml > 5.Download-Source.xml > 6.Case-Studies.xml > 7.License.xml > 8.Contributors.xml > 9.FAQ.xml > Sub--Projects/ > 1.Framework.xml > 2.Excalibur.xml > 3.Phoenix.xml > ... > Guides/ > menu.xml > For-Developers/ > menu.xml > I would probably express it a bit more future safe: 3 digit prefixes, and not using the full sequence right on 010.overview 020.nextone etc etc > with: > 1.Overview.xml = some document-v11.dtd doc > 9.FAQ.xml: > <item name="FAQ" ref="faq/"/> > 9.Framework.xml: > <item name="Framework" > external="http://jakarta.apache.org/avalon/framework"/> > Guides/menu.xml > <menu> > <item name="Developing with Avalon" > include="developing/"/> > <item name="Avalon for Beginners" > > external="http://jakarta.apache.org/avalon/excalibur/tweety/beginn > ers.xml"/> > </menu> > > etc etc. > > that the idea? > > I like =) > anything to please you chap :-) <snip subject="version numbers" /> > > we've got two weeks to get something working (one of our developers has > set a fair 'deadline'; see it as a challenge =); otherwise we'll likely > use anakia for the next 6 months or so.... > I don't know anakia, and can't expect you to dislike it as a solution I'll do a serious effort the coming week is the only thing I can say If you can still evaluate then ? Also, I'll be asking stupid questions to get around faster, so bear with me please... > > maybe we offer too much of detail configuration level to the end user > > ==what you (or an other) described earlier in the list as 'like a > > programming language' > > hmm. If you can auto-generate a complex file using a simple 'wizard', > then get all the power the complex file offers during tweaking, that is > nice. Nicola's got some ideas on this for centipede floating around. we can fix that later, I guess > > > > The thing with FAQs: they grow. You usually need to group > them according > > > to some order that cannot be machine-expressed. Ie the > question "what is > > > avalon?" needs to be question number one in category number one. > > > > > then call it 01.01.what_is_avalon.faq.xml, and let libre use > regexes on the > > filenames to get out what you want > > gotcha. > > > so we think that there could be a contract (== choosen > libre-strategy) that > > the MR can put down and communicate to the CR. > > That could be e.g. for the faq > > - (if you don't like xpath) use a naming convention for the > files so they > > start with 3 digits that make up the sequence order in which > you want them > > to show up, followed by the question that needs to show in the > menu, follwed > > by some .faq.xml suffix > > > > - (or if you dislike those ugly filenames) the strategy could > be such that > > menu-items are > > > > - (or if you think xpath is cool) the strategy could be that the actual > > content of the faq does sepcify its order. > > If you ask me, you should start with just a single strategy (probably > book.xml as most potential users already use it or something similar), > then implement more of those when it all works. > book.xml is the null-strategy, the actual ones kick in when you start using <auto> > Then again, I'm starting to like the express-more-in-filenames idea more > and more as I think about it... > Like any contract it can get dangerous, but if we pull it off for the complexity of avalon I think we have a major case. > > > > some fast information: > > > > - one of the already expressed feelings was that at least libre > > > > should do what book.xml is doing (not the case now) > > > > > > +1 > > > > > > > yep, just too foole quys like you to eventually use it anyway :-) > > actually the only thing we're missing now is the external links > of book.xml, > > the rest is there > > we need those =) > you'll get it, the strategies are harder, believe me > > > IOW, for the best site you need to do manual intervention in 99% of > > > cases. You don't want a menu sorted alphabetically, you want it sorted > > > according to some <XXX> human-interpreted sorting algorithm. > > > > from now called 'the strategy' :-) offering a set of rules > > the human can more easily stear the sorting then to edit the book.xml > > once again, start simple. Most cocoon guys I know have the general > tendency to implement everything at once. Might be their one flaw =) > there must be more wrong with them ;-) > > > I'm sceptical as to automating this. > > > > > > > I'm getting to repeat myself... but I basically agree. > > It's not as much about automating as it is about more conveniently > > expressing. > > we're definately on the same page. It's just the tone of the forrest > website suffers from the same problems as the avalon one: way too > technical without getting enough examples, context, and general idea > first. > hey, blame yourself, you're in a 4.1 release, we're just starting 0.1, remember ;-) > > this sounds like Nicola could give me a head start on understanding > > everything that is going on? > > (hey wait, centipede, isn't that 0.1 :-) ) > > =) > > I understand Nicola is active on forrest, which is why I mentioned the > project files. Integration with ant is instant added value; as is > integration with forrest. > I don't get this fully yet, but someone just told me I shouldn't try doing all at once :-) > > this is what forrest tries to become of course... > > I read in this thread that (you?) there were good vibes about the dtd's > > coming from forrest (it's docuheads over there off course, they > know what > > they are doing), I think there will be more to like in the > future (are the > > dtd's the only thing you use?) > > the thing I want most. Doc tools change, DTDs should stay the same. > question was: are you using the forrest (cocoonbased) generation process? or are you using ant and <style> instead? > > only it is a different group/project so it > > will not always follow the dynamics your team is dealing with. > > (maybe forrest-dev should think about some sort of stewardship towards > > supporting the project teams that want to start on it, that said, it > > wouldn't be bad for the doc-lead inside your project to start > biassing the > > forrest-dev :-)) > > uhuh. We've got Nicola =) he's everywhere if you ask me :-) > > > > then take a look at all 'src/xdocs' directories you can find > > > in our various CVSes, and see how that transforms into the site. > > > > jakarta-avalon module is the root that offers them all, right? > > yep, but when stuff works I'll move the 'root' to avalon-site. > > > > no thanks, I think libre has some ideas at the basis to realize > much of your > > visions > > (but obviously has not been doing a good job in making that clear to > > everyone) > > the forrest move around it facilitates even more, and it's only > by working > > together > > with actual project teams that all of it will eventually get used :-) > > > > there will obviously be more time and patience to be expected from both > > sides as we go allong :-) > > yup. I look forward to having a neat system to use; problem is ours has > been broken there is not so much patience left. But don't let that rush > you into bad releases though =) > patience is a virtue, as is working hard I guess... so if it comes from both sides we'll get there and euh, we already had one bad release :-) this time it feels like I could have a *user* which will (no doubt) make it infinitaly better regards, and be ready for some dull questions flying around tomorrow -marc= > cheers, > > - Leo > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
