[Seaside] Re: 2.5b2

[Avi Bryant]

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 
>> something?
>
> I have date/time inputs on my forms with these javascript masterpiece: 
> 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.