[Framework-Team] Re: Use cases for AZAX and KSS
ree at ree.hu
Sat Aug 12 05:37:25 UTC 2006
On Fri, 11 Aug 2006 10:25:40 -0700, Martin Aspeli wrote:
> So, to summarise:
> - You'd like to make a generic reload of contents/view/edit tabs - You'd
> like to use macro-rendering to do this - There is no generalisation or
> convention that can tell you which macro to
> - So you render the whole page server-side, and then strip out the
> unnecessary HTML
> The point is that you really want to render everything that's inside the
> metal:fill-slot="main". How about faking the acquisition context of the
> template when you run it so that it will find a custom main_template
> first? I think this is what Bling is doing with
I don't understand this. Is the content tab refreshment working with
Bling? And if yes, could you point to the bundle that I can just install
and see how it is working?
Let me elaborate a bit on my original question. As an example, consider
the following template:
force_fieldset string:Admin properties;
<tal:block define="dummy python: request.set('disable_border', True)" />
Let's not engage into a discussion if this solution is good, bad,
desirable or unorthodox. Point is, it is working, and the developer had a
reason to use this solution (for example, to get around some AT quirk).
Now, if the url path for this template is all the info what I get for a
given tab (as currently), how do I go on to find the content region,
starting from this template?
If you find the above case too extreme, just consider an ordinary template
thas has this scheme:
THR PART THAT I NEED
Even if the template looks like this (which we cannot actually assume),
how do I get access to the part under the fill-slot? I think Martin, this
is what you referred with the linking of the Bling template, but again,
either a deeper explanation or a working example is needed for me to
I hope these examples give a better context to my question.
Also to avoid misunderstanding I believe we need to decide what we talk
about at all:
1. Do we want to provide a solution that works with all the
(currently working) templates?
2. Do we want to provide the solution that only works with certain
templates, and force the developers to change all their products
3. Do we want to change the templating system of Plone in the future, in a
way, that all the "important" (i.e. reloadable) screen parts are
"viewlets" by design? (Independantly if a viewlet is implemented by a z3
viewlet or a traditional macro or just by adding some extra semantic
information to the system.)
In my view, 3 is the future, 1 is the present, and 2 is what I would not
find good to even think about. My reason is: if we want to do point 2, and
force a change to all the existing Plone products, why not do it in a good
way, according to point 3?
And even then I would keep backward compatibility with all existing stuff,
so imo, 1. must work in all cases. Also it is perfectly possible to do the
rendering in a way that if the template complies the new standard (i.e.
defines a viewlet for its content region), then that is utilized: if not,
we fall back to the currently applied solution.
> but I may be wrong about that.
Same about my reasoning, however I find the raised questions important
even in this case.
But in any case, if there is any smarter way to render the template, it
can be put into the server side method I am currently using. So
although the problem was raised by an AJAX use case, from this point
it falls back to an implementation question where no more AJAX is
involved, which makes the issue comprehensable for everyone.
I also crosspost this mail to the framework list.
More information about the Framework-Team