Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 85501 invoked from network); 3 Mar 2005 18:01:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Mar 2005 18:01:54 -0000 Received: (qmail 40888 invoked by uid 500); 3 Mar 2005 18:01:46 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 40809 invoked by uid 500); 3 Mar 2005 18:01:46 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@forrest.apache.org Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 40766 invoked by uid 99); 3 Mar 2005 18:01:46 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from natsmtp00.rzone.de (HELO natsmtp00.rzone.de) (81.169.145.165) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 03 Mar 2005 10:01:45 -0800 Received: from 192.168.0.107 (109.red-213-227-54.user.auna.net [213.227.54.109] (may be forged)) by post.webmailer.de (8.13.1/8.13.1) with ESMTP id j23I1YG1006767 for ; Thu, 3 Mar 2005 19:01:40 +0100 (MET) Subject: Re: [RT] Per document skinconf (was Re: coloring table cells [from the user list]) From: Thorsten Scherler To: dev@forrest.apache.org In-Reply-To: <42249147.9020207@apache.org> References: <421C4D94.6070905@uidesign.de> <421C7040.3090901@apache.org> <1109197348.5141.16.camel@localhost.localdomain> <421D1083.5090605@apache.org> <421D91D7.6010607@uidesign.de> <421DAD17.7070806@apache.org> <1109687343.6527.64.camel@localhost.localdomain> <42249147.9020207@apache.org> Content-Type: text/plain Date: Thu, 03 Mar 2005 19:01:22 +0100 Message-Id: <1109872882.5294.61.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Tue, 2005-03-01 at 15:59 +0000, Ross Gardler wrote: > Thorsten Scherler wrote: > > > > The problem that I see is that if you have a table with many colored > > fields and all have different colors that can be pretty soon overkill. I > > understand that the intermediate format should be clean of style > > information but I reckon it will be pretty hard to achieve. > > I disagree, for the use case we have here it is very easy to achieve > since all the CSS style information is generated by the XSL which > extracts it from the original source document. All that is required to > turn the hack solution in the OOo plugin into a solution that produces > valid XDocs is to create a separate pipeline to create the CSS sheet > rather than have it created as par of the intermediate XDoc. > I am sorry I did not had enough time to really get into the actual problem. In the Indesign Plugin I am doing a similar thing. I let the designer create all objects and styles and I just parse the content. I already have the content separated from the style at this stage. I only need to match from the user data to the design object. This matching is configured by forrest:views. forrest:views are just configuration files for controller and matching engine. In the end I would like to alter my application in changing configuration files (CheChe will now laugh ;-) when I meet him I think all my solutions ended up with a config file). I see the skinconf.xml problematic because there is not a common structure. Your solution as well is not abstract enough IMO:

true

false

When I want to match a new plugin I would need to add a new match in the controller. That is the reason why I would like to do it with forrest:views, where you have three different kind of main tags (so far) which all have certain functions. The other thing is I would like to have a skinconf per page basis, but that not make much sense if I am using our current skinconf because it is to mixed up. > > Now to the promised example, I would place the style information into a > > forrest:view like: > > > > ... > > > > > > > > > > > > ... > > > > Then I would add this to fileSpecific.ft (ft = forrest template) add it > > to an aggregation and match it in the xsl. > > > > In the document I would recommend to add an attribute > ft="color_ff0000"/> that will be matched in the xsl. > > How is this any different from as I was proposing? > It is not I thought it should not be done with @class. Sorry for the noise. > > I see a different attribute name, but not a different design. Wouldn't > it be better to stay consistent with XHTML2 since that will be our > intermediate format? > > The only other difference I see is where the CSS classes are defined. In > your proposal it is in a forrest:views definition file. In mine it is in > some other file (skinconf.xml, pdf-output.xml or whatever): > > > true > false > > > > > > I feel I must be missing something important about forrest:views ... > This discussion was a wake-up call for me to finish the fbits-plugin. I hope I can establish a proof-of-concept example with the forrest:views. > > > The whole thing do not have much to do with fbits. I am just using the > > forrest:views as config file format for the fbits. > > > > fbits are capsuled code snippets that can be called by a forrest:view. > > The fbit plugin has a method "get.fbits.*" (in form of an URL) which > > will return the snippets. * has to be replaced by the name of the fbit. > > Yes, love the idea of fbits. However, fbits are about content in the > page whereas this RT is about the subsequent styling of the page. I do > not think there is *any* overlap between the two stages of production. > ...and this point I see different. I see the problem as follow: In a skin there the content is placed on certain positions. The skinconf determines whether or not the content should be placed but not where. ok that is not 100% true because e.g. pelt have two different position for the breadtrail. I would like to use the skinconf in a way which will determine the position of elements. I see forrest:views as the next generation skinconf. I can place elements and e.g. the fbits will be then inserted on this position. I do not need something like true because if I do not place the in my view this link will not get rendered. Now where I see an overlap is that I could easily add css to the like (or similar)

That would solve another thing that I do not like on our current skinconf. The color tags are not self explaining. I would like them in the element that they are changing. The last thing that I do not like on skinconf that it is 100% forrest specific and I can not reuse it in e.g. lenya. Gregor wrote yesterday in the lenya-dev list: "the plus side of forrest plugins is that they exist today and address an area where lenya is weak today (resource type packages). on the minus side, it seems to rely heavily on skinconf.xml (very forrest-specific) and seems stuck in the DTD world. (note that i did not take a very close look, so i might be wrong)" I have to agree on BOTH minuses. ;-) > > It may make sense to move the style configuration stuff into > forrest:views when it is implemented, but I don't think we need to wait > for it since I believe such a change will only require a few changes to > the skining pipelines and stylesheets. > > Is there more to it than that? > Yes and no. IMO it will be a major break for skins, because there will be no more. Skins are not flexible. I want something that I can change within a minute without touching xsl code. It should be after the KISS motto. Keep It Simple and Successful. A forrest:view can alter a whole site or only pages. > > > The only problem that I am facing and that is why I do not really get to > > the point of releasing it is that I am facing the problem of how to > > resolve the variables of the snippets before I parse them to the code. > > > > e.g. POD -
> > icon

. > > > > I will have to return to work, but fell free to ask question and suggest > > alternatives. > > Sorry, I don't understand your problem, where is the code snippet from, > is it in the intermediate docs, the XSL. I'd be happy to try and help > solve this problem but you'll need to explain it more completely > (probably in a different thread). > You already did it (kind of). I was trying to reuse a lot of stuff without major changes, but I think that is not wise. I will try to hack a solution over the weekend and would be really happy if you (ant others of course) will comment on it. > > Ross -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)