[Cubicweb] annotating divs with rql and vid
pierre-yves.david at logilab.fr
Thu May 24 19:27:46 CEST 2012
On Thu, May 24, 2012 at 06:25:45PM +0200, Sylvain Thénault wrote:
> On 24 mai 18:09, Pierre-Yves David wrote:
> > On Thu, May 24, 2012 at 05:39:02PM +0200, Sylvain Thénault wrote:
> > > On 24 mai 17:25, Pierre-Yves David wrote:
> > > > > Giving argument to view is only part of the pb. Handling them dynamically
> > > > > in e.g. facets context without transmitting information all along the way
> > > > > is my concerns here.
> > > >
> > > > Why is it a concern to transmit information all along the way ?
> > > >
> > > > I'm curious to see your usecase requiring such optimisation.
> > >
> > > If you want to recall the view by an ajax call from the web ui, you
> > > need this information.
> > Right, the ticket does not explain this part.
> > In the pylos implementation, we explicitly declare possible argument for view.
> > This explicit declaration allows to automatically get current argument value
> > when generating ajax URL. Each argument values are expected to be found in
> > attributes with the same name than the argument.
> > example:
> > class MyView(self):
> > __vargs__ = ('arg1', 'arg2', 'arg3')
> > def call(arg1, arg2='babar', arg3='celestine'):
> > self.arg1 = arg1
> > self.arg2 = arg2
> > self.arg3 = arg3
> > This explicit arguments declaration is a small price to pay to get simple and
> > intuitive persistent parameter for view. In core cubicweb, this "only" requires:
> > - proper controler handling of "vidargs"
> > - unified way to generate ajax url.
> I'm not talking about generating ajax url. Facets are not based on that for
> instance. Following Nicolas proposal, we would need for instance to record the
> arguments on html attribute, eg '<div vid="myview" args="arg1='' arg2='babar'...">'.
Yes, once we know what parameter matter and how to get they current value it's
trivial to generate any kind of serialisation.
> I don't tell this is unacceptable, but it sounds awkward and ends up cluttering
> the HTML when carried by every reloadable component of a page, so it's worth
> discussing. Though I admit self-contained view, at least in their current shape,
> are not much nicer from a developper POV.
I do not see this extra information in html as an issue. Having them there will
all client side to alter current parameter value to reflect changes. It is very
useful for stateful form widget.
(we may ignore default value)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the Cubicweb