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. 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. > 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. > 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. > 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. > > Sooner or later our web interface needs a reboot to address these > > architectural deficiencies, and I don't think there is any advantage to > > pretending that this isn't the case. > > I disagree. > A decade of web framework design disagrees with you. Ian. -- Ian Clarke CEO, SenseArray Email: ian at sensearray.com Ph: +1 512 422 3588 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100212/aeb1e219/attachment.html>
