I agree with much of what you say concerning how concerns are separated. I'll only add that the proposed aspect is useful to a "specific site" as well as "generally useful" in that it would allow the site admin to define the content of the site separate from any specific theme in that site (i.e. Collection A vs Collection B). Thus it can be easier to have the same footer, header and option content across all the themes without having to replicate the inclusion of that customization into each and every theme.
This goes back to Dorthea's statement about wanting "theme inheritance" so that themes could be sort of layered on top of each other to bring together a presentation of based on parts managed in separate xslt. The aspects are already capable of this, but only in a content centric way. I went through the SoC / MVC2 approach vs Content+Presentation all in one place a few years ago. I was strongly for the "later" until I'd created a site that was large and had many pages, then it became a nightmare... We quickly went for a MVC2/SoC approach then which was struts. Keeping content and presentation separate is important, but doesn't mean you have to be draconian about it. As the themes and aspects for your site evolve, you should revisit the subject of what is content and what presentation and try to organize if its possible. But your not a "bad developer" if you don't. ;-) -Mark On Feb 5, 2008, at 1:11 PM, Mark H. Wood wrote: > Here's how I see it, FWIW. > > 1 The aspect chain collects all of the information that might be > relevant to a query, and throws it all in a bucket. That bucket is > the DRI document. > > 2 A theme fishes around in the bucket, pulls out all of the > interesting stuff (according to the theme's designer's > understanding of what's interesting), and lays it out on the > final page, embedded in static content. Anything not interesting > is just ignored, same as HTML-ish tags that your browser doesn't > recognize. > > 3 Stylesheet references (CSS -- I don't think of XSL-T as styling) > sculpt the detailed appearance of the page when it's rendered. > > Look-and-feel is created by steps 2 and 3. > > This arrangement makes it easy for different parts of the repository > to present different subsets of the information about a given object. > The aspect chain throws in *everything* and then the selected theme > filters out only what it wants. If you develop object-specific > information in a theme, the technique has to be copied every time you > want to do that in another theme. If you do it in the aspect chain, > then every theme immediately has access to the new information and can > use it or not as desired. > > Another consideration is that themes are more likely to be specific to > a single site, while aspects are more likely to be generally useful. > This distinction makes it easier to share a cool new feature you've > developed without having to disentangle it from the particular > presentation you use. > > -- > Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] > Typically when a software vendor says that a product is "intuitive" he > means the exact opposite. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
