Joern Nettingsmeier schrieb: [...]
>> The menus contain a lot of functionality. The usecase framework has >> improved this a bit, but has also brought a performance penalty. >> I wouldn't like to put more logic in XSLTs. I agree that XSPs are bad, >> we have to find a way to move the logic to Java classes or another >> reasonable language. > > i think you may be a little biased against xslts... I used to like it a lot, and I still like it for certain purposes, but it tends to get in your way when you try to increase the performance. > sure, the language > is verbose, but it *is* possible to write quite elegant stuff with it. > even more so with xslt2. i think it is quite natural to implement menu > semantics in xslt. and what we currently do is not exactly rocket science. > if we're going to make any fundamental changes to how the GUI works, we > should rather introduce ajax and do the interesting stuff on the client. +1 >>> and please pretty please not another java-based buzzword-of-the-week >>> template atrocity. angle brackets are good, curlies are bad. :) >> >> Well, that has to be decided for our project. >> History seems to show that XML is in general not the best choice >> for DSLs. The Cocoon people also considered to move away from XML >> for sitemaps. > > what are DSLs? Domain-specific languages > why debate XML? XML by itself means nothing and does nothing. it's just > an agreement on a very simple syntax with tried and true parsers and a > tree paradigm. that does not imply anything. every procedural or oo > language can be represented as a tree (think stack frames). IMO XML is good for data, but not for the description of processes. Our menu is a special case - it has a basic structure (which XML is fine for), but there's some logic to control the details. We have to find a way to separate these aspects, maybe by introducing a generic mechanism to show/hide/enable/disable menu items. > ok, it's tedious to type. > show me another nice syntax that comes with excellent parser > implementations for all major programming environments, a > turing-complete transformation language and a grammar description > language that allows for automatic validation. then let's count how many > people work on that compared to how many people work on xml... XML has its fields of application. But I wouldn't like to implement an OS core in an XML-based language :) > i think the evil thing about sitemaps are the many custom components. > the core sitemap language needs to be more powerful... Yes, that's an important point. Virtual pipeline components could improve this a lot. [...] >>> sorry to be so negative, but i think we have painted ourselves in a >>> corner big time. it's nothing that would endanger 1.4 or reduce its >>> usefulness, but we are at a dead end now wrt URL handling. just look at >>> the mess: >> >> IMO that's not a mess, the only thing I don't like is that the >> page-envelope module mimics the behaviour of other modules, >> violating orthogonality. We already started to improve this situation, >> but it needs more work. > > i did not intend to bad-mouth the work spent on that. the problem is: > the moment we introduce a new, correct method to do something, the old, > deprecated stuff must be eliminated asap. You got me there, that's really a broken-window issue. But it's a long way to go, and we have to get 1.4 out ... > "there's more than one way to do it" is a nice fairytale from perl land. > on this planet, it usually becomes "there's more than one way to do it > subtly wrong". > > everybody learns by example, and currently nobody but you seems to know > what the correct method for URL handling is. I'm afraid I don't know it well enough, otherwise I could help with the proxy issue :) Most things I know are in the docs: http://lenya.apache.org/docs/1_4/concepts/urlMapping.html http://lenya.apache.org/docs/1_4/reference/link-management.html > i only found out about it > because i tried proxying. > > that means we cannot tolerate anything less than best practice code in > the core, else we risk that all user contributions and custom extensions > are fundamentally wrong and will easily break. +1 -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
