Hi Cemal, Yes you are right. I'll keep the details for our private communications... My apologies if I have been a bit pushy on this matter...
Best regards, Ernesto On Wed, Mar 3, 2010 at 10:42 PM, Cemal Bayramoglu < [email protected]> wrote: > Ernesto, > > Thanks for putting so much time and thought into your project and your > response. > > Our jqGrid implementation has been gathering dust for several months > in our own repository but we do like to work on it when we can, and > Richard keeps an eye on interesting features the jqGrid guys introduce > so we can expose the ones we like via our component. > We've only just unveiled it here, even though it is not ready to be > opened/released, because we are keen to get the gitHub hosted wiQuery > plugins project off the ground promptly so we can have discussions > such as this (very detailed and specific to wiQuery plugins) in a > central place and benefit from the ideas and effort developers like > you are generously and eagerly already putting in! This will also give > you the access we have not yet been able to grant you so far to our > code base, so you can contribute directly to the evolution of these > new wiQuery components if that makes sense for you. I can already see > that you are in a good position to speed up the development process on > this component, > > In the meantime, I suggest we keep the detailed emails like this on > our own "private" thread that you mentioned below and that I started > for all directly interested last week so all this useful information > is not too scattered and hard to find. > > You will also learn tomorrow from Lionel that we have some interesting > ideas for further, reference components that will be a great place to > direct your contributions while we get ready to open these components > too. > > Regards - Cemal > jWeekend > OO & Java Technologies, Wicket > Consulting, Development, Training > http://jWeekend.com > > > > On 3 March 2010 21:13, Ernesto Reinaldo Barreiro <[email protected]> > wrote: > > Hi Richard, > > > > Some of these I already answered in a "private" e-mail... > > > > Just about XML vs JSON. You can have a flag on the grid that decides XML > or > > JSON and then transparently generate one or the other.... See for > instance > > > > > http://code.google.com/p/wijqgrid/source/browse/trunk/wijqgrid/src/main/java/com/wijqgrid/component/GridXMLData.java > > > > and how it is used on > > > > > http://code.google.com/p/wijqgrid/source/browse/trunk/wijqgrid/src/main/java/com/wijqgrid/component/Grid.java > > > > The original grid supports either XML or JSON. Why not support both of > them > > then? > > > > Regarding events see: > > > > > http://code.google.com/p/wijqgrid/source/browse/trunk/wijqgrid/src/main/java/com/wijqgrid/component/#component/event > > > > Best, > > > > Ernesto > > > > On Wed, Mar 3, 2010 at 7:17 PM, Richard Wilkinson < > > [email protected]> wrote: > > > >> Hi, > >> > >> John - im not to sure what you mean by row expanders, is that similar > >> to what is provided on the tree grid? > >> > >> Ernesto - see comments inline: > >> > >> > >> On 3 March 2010 12:59, Ernesto Reinaldo Barreiro <[email protected]> > >> wrote: > >> > Hi Cemal, > >> > > >> > Other things that might be useful: > >> > > >> > -Offer (pluggable) support for grid events at client and server side > >> (e.g. > >> > been notified when user navigates between pages, sorts a columns, > etc). > >> By > >> > pluggable I mean they can be enable if you need them so that no > >> unnecessary > >> > server round trips are made. > >> > >> The gird always has to make a request to the server when the user > >> navigates between pages, or changes the sorting, since this requires > >> updated data. However these events are handled internally to the grid > >> code and are not accessible to the developer. If required we could > >> make these events accessible to the developer, either through adding a > >> behaviour, or overriding a method. Other things such as selection > >> notification events, or editing, can optionally be listened to by the > >> developer, but these do not make a round trip to the server unless > >> they are explicitly added. > >> > >> > -Show an example of how the grid interacts with a normal wicket form. > >> E.g. > >> > have a form the is submitted via Wicket AJAX and get the grid > refreshed > >> > either via Wicket AJAX (i.e. the whole grid component is reloaded) or > >> > triggering a reload event on the grid (I see the master detail example > is > >> > built using this last approach?) . > >> > >> yes, this page (http://labs.jweekend.com/public/gridjpa/ProjectEditPage > ) > >> uses a wicket form (not automatically generated though) to edit a row > >> in one grid, which then triggers a data refresh in both grids, but > >> does not do a wicket ajax component replace. However ajax component > >> replace is supported as there is an AjaxRequestTarget, but I feel that > >> forcing the grid to reload is cleaner. > >> > >> > -All the examples seem to use JSON for data transfer? Is XML > supported? > >> > >> The grid uses JSON, however this is all internal and transparent to > >> the developer using the grid, so I dont see how supporting XML would > >> be a benefit. It is not possible to construct JSON or XML and feed > >> this into the grid manually, i.e. by telling the grid which url to > >> use. > >> > >> The intended use is the same as with a Wicket DataTable, where an > >> IDataProvider provides an iterator of beans which are rendered as rows > >> in the grid. We use Wicket IConverter to convert each field of the > >> bean to a String, then use a JSON library to construct the JSON > >> response, which is then used in a custom wicket IRequestTarget for > >> JSON. > >> > >> > > >> > Best, > >> > > >> > Ernesto > >> > > >> > On Wed, Mar 3, 2010 at 11:33 AM, Cemal Bayramoglu < > >> > [email protected]> wrote: > >> > > >> > >> > >> > >> -- > >> Regards - Richard Wilkinson > >> Developer, > >> jWeekend: OO & Java Technologies - Development and Training > >> http://jWeekend.com > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
