This is in response to a somewhat more detailed message
matthew sent to
the scooby team a few day ago, there were some relevant
issues to add to
the debate, so I wrote a few comments to explain some of my
engineering
decisions... Mostly to keep the interface and architecture
debate open.
Matthew Eernisse wrote:
>
> PROCESS
>
> 1. Communication (obvious, yeah)
>
> I think we ought to have had more frequent or better
communication.
Yep--
>
>
> 2. Working with Scooby code
>
> The code submission could have plugged into the
existing Scooby code a
> bit better.
So this was an interesting issue I had as a contributor. The
scooby team
is engaged in significant debate concerning the architecture
of the
browser client. In approaching it, I took the option of
keeping the
minical almost entirely self contained, with minimal and
unique join
points to cal_main. It would have helped dramatically if
cal_main was
organized to present a clear API or interface for outside
consumers of
its data. I do not ever like to access properties directly,
because it
makes me dependent on internal code structures and limits
the ability
for a module owner to make changes. The calendar view and
controller
were tightly integrated as interfaces were not a priority
for initial
development, but that closeness also made for some difficult
choices in
integration. A you own scooby's front end, and I am a
tourist, it made
sense for me not to mold code you must maintain.
My original submission was deliberately communicating with
the interface
I wanted, not the interface that existed, if for no other
reason than to
spur the interface/api discussion.
> We now have a JavaScript styleguide to address this
issue:
>
> http://wiki.osafoundation.org/bin/view
/Projects/ScoobyJavaScriptStyleguide
>
>
+1 to that
> 2. UI-element widths in 'em'
>
> I changed widths either to hard pixel widths or
percents. I prefer not
> to use em for widths of non-font elements when the UI
element sits
> inside a fixed-width container. And since ems are a
compounding unit,
> changes to font sizes in elements above the element
will change its
> width.
>
That is your decision as the owner of scooby code, but its
worth opening
up the discussion-- I believe using em's is a valid way to
do things,
and that kind of scaling should become pervasive. But that
is just an
opinion-- my real point is that graceful scaling is a
prerequisite in
design for disability, and that font size and not screen
dimensions
determine layout.
In point of fact the Minical should scale gracefully in this
respect
>
> 3. The month-to-month nav
>
> I changed this code to use DOM methods to create the UI
elements,
> since the code in the initial submission was not
functional, and it's
> just a simple three-column table.
In the original submission it wasn't implemented, which is
why I fixed
it for the later one ( ahh communication....) In any case, I
used
innerHTML for two reasons: 1) its faster for prototyping 2)
it actually
renders in browser much faster than DOM methods. That
doesn't make it
the right way however....
> 4. The id property for day cells in minical tiles
that was intended to enable months to act more fluidly. To
implement
infinite smooth scrolling, months only own tiles
temporarily. I did it
to reduce the need to create a new months by swapping. It
actually works
in the last drop I sent, unlike the first one. Ahhh
Communication. There
may be other strategies...
>
> 5. Dimmed dates
>
> I also added the dimmed dates
cool. I wasn't looking forward to it.
>
> 6. Selection rendering
>
> Rather than using constants for a preset list of
selection ranges, it
> makes more sense simply to highlight the dates from the
beginning to
> the end of the query range. The main Cal object has the
viewStart and
> viewEnd properties that are already used to perform
queries on the
> Scooby service.
So how are we managing selection? I assumed a couple of
things
1) if there was no publicly exposed API I should manage it
internally.
2) selection length may determine the main calendar view (as
it does in
other clients) i.e a 7 day view is rendered very differently
than a
month view , a two week view, or a five day view, at least
in
traditional calendars. I saw the constant as a way to choose
a renderer
for the date (and by association a renderer for the main
calendar) This
is an interesting issue related to how minicals control main
views,
particularly in calendars following the outlook model: by
clicking and
dragging in the selection in those minicals you can set both
the
selection and the view type-- in outlook dragging from 5
days to 7 moves
you from a linear view as we currently see to a
week-at-a-glance view.
This brings up an interesting point about how the query
ranges are
established by selection-- I could not see a clear API so I
asusmed a
current selected day, which then set selection according to
the current
view (week, next four days, business days, month, etc...)
The offsets
required would change depending on the view, hence the use
of renderers
in stead of a selection view.
> I want you to know how much we appreciate this
contribution. This is
> hugely significant for us for many reasons.
>
glad I could help.
J
_______________________________________________
scooby-dev mailing list
scooby-dev lists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev
|