[Seaside][ShoreComponents] DatePicker discussion
avi.bryant at gmail.com
Sun Sep 25 05:16:27 CEST 2005
On Sep 24, 2005, at 6:32 AM, Michel Bany wrote:
> I ported the Shore date picker widget to VisualWorks and I wanted
> to discuss some of the difficulties I had.
Thanks; it's great to see discussions of the problems people are
running into. Consider this an open call for similar such stories :)
> 1) The Shore date picker is based upon the Squeak version of the Date
> class. The VisualWorks version of the Date is somewhat incompatible
> and I had to convert the VisualWork Date objects to Squeak.Date
> (for those who do not know, the VisualWorks version of Seaside
> a port of the Squeak chronology subsystem in a different namespace).
In which ways are the Date objects incompatible? Rather than
maintaining Squeak.Date, can we come up with a common protocol that
can easily be implemented with a few extensions on either side, so
that at least basic date code is interoperable between Squeak and VW?
> 2) Addding to the onclick attribute. Currently, coding something
> like this
> generates the onclick attribute twice in the html tag, making the
> uncompliant to xhtml.
> Therefore I had the idea to implement this
> The implementation is equivalent to at:put: when the attribute was
> never used before. It concatenates the old value with the argument,
> inserting a semi-colon otherwise.
> In my opinion, a lot of thinking is still needed there.
This makes sense. It's very useful for the 'class' attribute as
well, although without the semicolon separators. The Canvas
implementation has an #onClick: method that I will adapt to use
this. Perhaps we should add one to HtmlRenderer as well.
> 3) Even with the above issue somewhat solved with at:append: we need
> a technique for telling the date picker component that we want to
> append something to the onclick attribute of the calendar cells.
> The problem
> is that sometimes we want to submit the form, sometimes we do not
> want that.
> My suggestion is to add a notification in #openTag: before opening
> the html tag
> openTag: aString
> TagNotification raiseRenderer: self tagName: aString.
> self document openTag: aString attributes: self attributes.
> attributeBuffer := nil.
I'm concerned about the performance implications of signalling a
notification on every single openTag:. At least in Squeak, I think
that will add a ton of overhead.
If you give your elements ids, couldn't you do something like this?
(Not sure if my JS is correct here).
html datePickerOn: #dateScheduled of: self.
html script: 'document.getElementById("someElement").onclick =
More information about the Seaside