[Seaside] Re: 2.5b2
kamk at volny.cz
Wed Aug 4 16:50:30 CEST 2004
Avi Bryant wrote:
> I think #addHeadElement: will stick around. But if you find yourself
> using it, it's a sign that there's a missing convenience method. What
> kind of elements are you adding? You need #addStyleLink: or something?
http://dynarch.com/mishoo/calendar.epl; It's a couple of script files
and one stylesheet file. Right now I link it with these external files,
but once style/script libraries will work I may include it into the image.
>> - now updating document's title from #updateRoot: in the root
>> component. Perhaps there could be better way for a component to
>> alternate document's title.
> Perhaps. But what? :) Do you have any suggestions?
Hmm, maybe for start it would be pretty enough to have something like
#alternateTitle: taking and returning a String. Maybe someone has other
idea like of more advanced "title handler" (I like the name :)
> ... The idea I was starting with was
> that you should be able to easily find the appropriate styles for a
> given component using the halos, which is what the #findStyles stuff and
> the search box in the library browser are all about. But they're very
> much works in progress, and all suggestions are appreciated.
It looks promising. Given the list of IDs and CSS class names, the
designer would just style the application as if it would be colouring
book. One more thing; I noticed that in rendering methods in model
protocol such as #textInputOn:of: there is a setup for element's id. It
makes annoying bug of multiple ids in case:
html textInputOn: #property of: data1.
html textInputOn: #property of: data2.
Is there that id needed for something?
>> How do you like the idea of having classes such as WAScriptContent ...
>> WAStyleContent ...
> So you would have one class per style instead of one method per style?
> That might be ok. I think there should still be an easy way to package
> them up into "suites" for easy inclusion (StandardStyleSuite, etc).
Yes, one object per stylesheet. I completely agree with suites.
>> - no remove action for "config" in "config" web application
> That's intentional. Why do you want to remove it?
Urgh, what happens when I remove it? Feels like cutting tree branch you
sitting on :) Definetely there must be way to bring it back, just let us
know how to :)
>> - in configuration window, button "Save" packed within "General" section
> Put Save with General, and keep Done where it is now?
Yes, just group submit buttons with forms. Setting for base path would
have to go into "General" form as well I think.
More information about the Seaside