On past projects I've handled maintaining selection of lazily-replicated
datasets by (a) keeping the selection information in the data and (b)
retrieving "change packets" from the back-end rather than refreshing the
data wholesale. I'd argue that it's dangerous to try to maintain
selection based on index in a replicated dataset if the data's changing
under you - this may not be the case in your situation though.
Catching when the lazy replication "finishes" was difficult in my
application because (a) replication container's size was based on a
combination of the size of the replicated views (which increased as the
replication occurred) and a maximum size imposed by its container and (b)
the size of the replicating container also changed based on the size of
the browser window.
Check out the LzDataSelectionManager. I ended up implementing a
GridSelectionManager with a similar API to manage selection in my more
complex instance. You may need to do extend LzDataSelectionManager with
the ability to select a non-displayed dataelement.
Then maybe you can submit your change to the platform. :)
-e
On Thu, 9 Feb 2006, James Howe wrote:
> The main reason I want to know is that it seems that if replication isn't
> done, I'm not able to select a particular item. For example, my grid displays
> a list of items. A user can select one row which display some other
> information related to that item. Periodically the grid may refresh itself
> from the server. I don't want the selection to change just because the data
> refreshed. I want to reselect the same item as before. I'm using an ID
> associated with the row so even if the position of the object changes, I can
> still find it. To date, I have been unable to get anything but a
> selectItemAt(0) to work, and even that only works part of the time. I assumed
> it had something to do with the replication, but perhaps that's not the
> problem.
>
> Of course, this raises an interesting question. Suppose the user has selected
> the 500th object in the list. The grid is using lazy replication. When the
> grid refreshes I want to reselect the same object (from a logical
> perspective). Perhaps the object is now at position 480. With lazy
> replication, will I be able to find out that the object i'm interested in is
> at position 480? Right now I'm using an xpath query to find a data node and
> then telling the grid to select based on that data. Of course, as I mention
> above, that doesn't work, even for a small number of items in a grid.
>
> Any thoughts on how to make this work, with or without determining when
> replication has completed, would be appreciated.
>
> Thanks.
>
>
> On Thu, 09 Feb 2006 17:59:31 -0500, P T Withington <[EMAIL PROTECTED]> wrote:
>
> > I'd be interested to know why you need to know when replication is done.
> > I'd like to see an easy way to do this that did not involve counting clones
> > and adding delegates, but every time I've thought I really needed to know
> > when replication was done, it turned out there was a different way of
> > looking at my problem that did not require it. For instance, it is usually
> > sufficient to add a handler for oninit in the replicated nodes.
> >
> > On 9 Feb 2006, at 17:39, James Howe wrote:
> >
> > > I've been trying to figure out how to know when data replication has
> > > finished with a grid. I've looked at the examples which use List or other
> > > components, but Grids seem to work differently. I think it has to do with
> > > the fact that grids have both a datapath and a contentdatapath, and it's
> > > the contentdatapath which triggers replication. In most examples I've
> > > seen for dealing with data replication I'll see something like this:
> > >
> > > <class name="repltabelt" extends="tabelement" text="$path{'@name'}"
> > > visible="true"/>
> > > <tabslider width="150" name="gs" height="150" spacing="2">
> > > <repltabelt name="pane">
> > > <datapath>
> > > <method event="onclones">
> > > if (!this['doneDel']) {
> > > this.doneDel = new LzDelegate(this, 'openOH')
> > > this.doneDel.register(clones[clones.length - 1], 'oninit')
> > > }
> > > </method>
> > > ...
> > > </datapath>
> > > ...
> > >
> > > In this example, if I'm interpreting it correctly, the datapath associated
> > > with the 'repltabelt' will trigger clones and the code can hook into this
> > > by adding a method to the datapath (via <datapath>) to catch and do
> > > something with this information. A grid is more like:
> > >
> > > <grid datapath="..." contentdatapath="...">
> > > <gridcolumn datapath="..."/>
> > > <gridcolumn datapath="..."/>
> > > </grid>
> > >
> > > The replication is on contentdatapath. How do I define a method to handle
> > > the onclones event in this situation? It seems like things would be
> > > clearer if grids were defined like this:
> > >
> > > <grid datapath="...">
> > > <gridrow datapath="...">
> > > <gridcolumn .../>
> > > <gridcolumn .../>
> > > </gridrow>
> > > </grid>
> > >
> > > where the datapath for the gridrow was what is currently known as
> > > contentdatapath in grid. Then you could use the <datapath> syntax on
> > > <gridrow> to define the onclones handling method.
> > >
> > > Anyway, does anyone know how to deal with 'onclones' with respect to the
> > > contentdatapath in a grid?
> > >
> > > Thanks.
> > >
> > > --James Howe
> > > _______________________________________________
> > > Laszlo-user mailing list
> > > [email protected]
> > > http://www.openlaszlo.org/mailman/listinfo/laszlo-user
> >
>
>
>
> --
> James Howe
> _______________________________________________
> Laszlo-user mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
