[Seaside] Re: 2.5b2
avi at beta4.com
Wed Aug 4 19:21:35 CEST 2004
On Aug 4, 2004, at 7:50 AM, Kamil Kukura wrote:
> 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
> 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.
FWIW, that date/time input doesn't seem to work properly in Safari,
although it claims to. No idea if that matters to you or not.
>>> - 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 :)
Yes, this is pretty much exactly what I originally had, but I'm not
convinced it's better. I think the main problem I have with it is that
there's no way to extend the protocol: you're always just receiving a
string and returning a string. If you have an object (like the root)
that you're manipulating, you can add methods like #extendTitle: or
#addSubTitle: and play with the implementations of these, rather than
hardcoding the string concatenations in #alternateTitle:.
> 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?
No, it was just a bad idea. I thought I'd gotten rid of all of those
implicit CSS ids, but I guess I missed that one. Thanks.
>>> 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.
Ok, I buy that. What do others think? And should this be a change to
2.5, or go into 2.6?
>>> - 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 :)
Oh, that's funny - I was thinking that there already wasn't a remove
link, and that you were saying there should be. I should have checked.
Yes, I'm perfectly happy to not have a remove link for the config app.
More information about the Seaside