On Mon, 2005-08-15 at 12:52, Lance Lavandowska wrote: > Please excuse me, it's been awhile since I looked at the code, and I'm > not in a position to at the moment. > > For you, as any existing user, it is a problem that needs to be worked > around. You are correct that simply looking for the existence of > _decorator was a mistake. > > You can get around the problem by defining a _no_op_decorator and > specifying $decorator=_no_op_decorator in your css template. In your > case it would be better to upload a local.css file and point to that > instead (additionally you avoid the overhead involved in invoking the > PageServlet), unless you have some sort of server-side processing > happening.
true, but this is cumbersome and cryptic as well. normal users should not be expected to do something like this. > > ... more below the quote ... > > On 8/15/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > We can make it easier for users by eliminating this option (to all > > > appearances, but maintaining backward compatibility). > > > > i disagree. i don't think we can hide this feature and still make it > > truly useful. if a decorator is going to be selectively applied to only > > chosen templates then this must be done via the UI. > > I guess I don't understand you here. How would you identify > decorators which could be applied to any given template? If you can > find good UI solutions to applying your ideas I welcome them. i haven't done much more than think about this in my head, but what I am thinking is that we take the current table on the templates page and just add another column for "Apply Decorator?" and that can identify if the decorator is applied to the given template. an example line might have ... ------- Weblog, Weblog, Weblog, check (decorator applied), edit link, (required) _css, local.css, site css, empty (no decorator), edit link, (required) ------- but that is just an idea. -- Allen > > Lance
