On Saturday 13 February 2010 02:35:43 Ian Clarke wrote: > On Fri, Feb 12, 2010 at 6:19 PM, Matthew Toseland <toad at > amphibian.dyndns.org > > wrote: > > > This was not explained in your prior email. And I disagree. HTML is > > supposed to be used for structure, there is nothing wrong with structure in > > code. > > Almost any designer would disagree with you, as would any software engineer > with experience building web frameworks. Find me a web framework that > doesn't use some form of templating to separate HTML (and CSS) from code. I > doubt you can.
IMHO we are talking past each other because we have a different understanding of "presentation". Here is my hypothesis: I have been taking a narrow, page-level view of presentation: What goes on which page is hardcoded in the Java code, output as HTML, and then CSS transforms that raw data into something that looks reasonable. As evanbd has pointed out, structured data for a single page can be converted into almost any visual layout. And we use javascript to update the data. You have been taking a broader view of presentation: What goes on which page is *part of the presentation layer*. Hence the need for a templating engine. These are typically at least a megabyte of runtime jar (which is why we haven't used them in the past), they mix code with some sort of php-like programming language, and they expect the backend to expose data structures via some sort of query language. I'm not aware that GWT actually does this but for all I know maybe it does; I've only seen it used for modifying HTML. Is this a reasonable analysis? If so, my objection is that this is unnecessary complexity. We do not need the ability for different themes to put different things on different pages. We are developing a single UI. Themes are nice but it really doesn't matter whether they can change what is on what page, as long as we have a good overall structure. If pupok was an expert in one particular non-java templating language I might understand the desire to separate things like this. But GWT actually uses Java itself, so there is no need for a query language and a hundred XMLHttpRequest's before displaying each page: You can as easily modify the java on the server side as on the client side. All we have to do is this: - pupok develops a mockup, working from the user's requirements and not from the current state of the UI. - this mockup includes elements that are shared between different pages, it includes the general style, it includes the layout and specific content of specific pages. - it is highly unlikely to be comprehensive. - we change the global theme to implement the general style. - we change the specific pages to implement the layout and specific content of specific pages. - we use javascript to keep stuff up to date that needs to be kept up to date. > > The idea that HTML must be separated from code has been common wisdom since > the late 90s. HTML must be modifiable by the designer, and it isn't if its > embedded in the Java code. In the late 90s the reason to separate HTML from code was that you did almost everything with tables and other highly dubious HTML presentational elements. Nowadays you do presentation stuff with CSS. XHTML actually has very little presentational stuff in it, just a bunch of defaults which are easily overridden. > > > Presentation should not be in the code, and neither should english strings, > > but they are not (okay, 99% of the time they are not). > > HTML is presentation. Ok, its not all of presentation (some stuff is in > CSS), but HTML definitely is presentation. Talk to any designer and ask > them if they can change a design through CSS alone and they'll think you are > joking, I promise. If you regard structure as part of design then of course this is true. However IMHO hardcoding structure in the server-side HTML generation is easier, as well as more efficient, than using a query language to construct each page. > > > Yes it would be possible to express structure with a different language, > > say XML, but there would be no benefit, the outcome would be exactly the > > same, and the way we do it now we get compatibility with > > old/non-js/accessible browsers for free. We then convert structure to > > presentation using CSS (which can do *almost* anything, including drop-downs > > and menus), and we use Javascript for live data updating and occasionally > > for update-in-place interactive stuff. > > > Your idea of the boundary between code and presentation is incorrect. It > isn't between HTML and CSS, its between the code and HTML. > > > > You may accuse this of being a 1999 model, but it's a perfectly good model. > > > It is a 1999 model, and it isn't perfectly good which is why nobody else has > used it since about 1999, nobody sane anyway. All web frameworks treat both > HTML and CSS and presentation, and consider it very bad practice to have > HTML in code. They know what they are talking about. Nobody used it in the late 90s because they had to use tables and spacer gifs because there was no good presentation transformation language. Once there was one, the W3C's preferred model of structure in HTML (or XML) and presentation in CSS became feasible. > > > I know a lot of work has gone into FProxy, but that fact alone cannot > > > prevent us from considering the pros and cons of replacing it. We've > > thrown > > > out a lot of code over the years with Freenet, its an essential part of > > > software development. > > > > I agree, but I have not seen any credible reason to throw out fproxy just > > yet. > > > > > > Regardless, nothing will get thrown out any time soon, we'll be lucky if > > we > > > get a new UI for Freenet 0.9. > > > > So you've given up on deploying a half-baked UI in parallel to the main UI > > in a shipped release? If so that is progress... > > It was never my intention that this would be made the default in the > near-term. As I said, I expect 0.9 will be the first 0.x release containing > this new GUI, if it ever gets implemented. Okay. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100213/1f7371fd/attachment.pgp>
