[Kss-devel] How to make the load-event?
Balazs Ree
ree at ree.hu
Mon Jan 22 13:47:46 CET 2007
Hi Christian,
2007. 01. 19, 11.48-kor Christian Klinger wrote:
> as some of you know, i did some work in KSS in autumn.
> A result of these work is the KSSMasterSelectWiget, based on the ideas
> of Alec´s work in MasterSelectWiget.
>
> Now i want jump into the development of KSS again. The target of this
> project should be
> a new Version of KSSMasterSelctWidget. In particular the part with hide
> and show fields
> base on a selection.
>
> I hope you can give me some ideas how to do that in a more "KSSish" way?
>
> If i rember correctly ree say that the kss load
> div.ArchetypesKSSMasterSelectWidget input:load {}
> event is not a good option for this. Can you give me an example
> how i can make this better?
The main pattern that we apply in a lot of use cases is that the static
template (zpt) is able to generate the initial version of the widget. So
also later on we can call up the server and make it re-generate the
entire widget (but not the rest of the page) with the new parameters,
and we simply replace it on the client side. This is a very powerful and
easily implementable approach, taken that you already have the original
templates anyway. More advantages: no need to keep in sync the code on
the client and on the server side, in case you or someone decides to
modify the widget. Since all logic is on the server side. The price is,
obviously, a few extra ajax requests.
However you take a different approach in the MasterSelectWidget
template. When the templates arrives to the client you trigger a series
of load events, they call up the server, and the server instructs the
client to change various parameters in the dom. This approach has a few
disadvantages but also can be equally powerful if used appropriately.
Howewer the result is that already when the page arrives you have to
issue a series of ajax requests, which seems a problem since they would
be avoidable in another way. And we are not even talking about dynamic
behaviour at this point, just the initial pageload. Note that the load
events are really only effective if they execute client actions and
don't call up the server right away.
To implement this approach effectively, we would need that kss is able
to push commands that travel together with the initial html response.
This way you would not need extra ajax requests on page load and your
widget code could instruct the client "if kss is active do this and this
on the loaded page as soon as it is loaded". This seems like a useful
thing and I am sure we will have this at one point. However situation is
that everything not needed directly for Plone 3.0 becomes low priority
for now, and we have to postpone the implementation of this and various
other equally useful features until later.
There is one last thing that I would like to mention. We need to
establish a strict policy that every page must be equally functional
without kss (or javascript) present. This is because we want to keep
accessibility. Now I am not saying that MasterSelectWidget breaks this
principle, I just found it important to notice here.
For the next week I suggest that you keep on eye on the progress we make
on the SnowSprint, it would be even greater if you could join us
personally on one of the upcoming sprints soon.
Sincerely,
--
Balazs Ree
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ez az =?ISO-8859-1?Q?=FCzenetr=E9sz?=
=?ISO-8859-1?Q?_digit=E1lis?= =?ISO-8859-1?Q?_al=E1=EDr=E1ssal?= van
=?ISO-8859-1?Q?ell=E1tva?=
Url : http://codespeak.net/pipermail/kss-devel/attachments/20070122/10dea990/attachment.pgp
More information about the Kss-devel
mailing list