[Infusion-users] Reorderer component persistence

Justin Obara obara.justin at gmail.com
Fri Apr 30 16:11:12 UTC 2010

Hi Marcus,

Thanks for your feedback.

Currently you could take a look at our nightly build of uPortal which includes an example of a persisted reorderer. (See: http://build.fluidproject.org/ )

We do have plans to update our demos. However there is no specific time frame for this at the moment. I do think your idea of using cookies should be doable. We currently make use of a similar strategy for our UI Options demo. If you are interested, we could work with you to implement an example with a persisted store. 

As for github, our code is currently in an svn repository, which I don't believe would work on github. That being said we are starting to think of using a decentralized repository.

Here is a link to Infusion's trunk.

Thanks again for the feedback, and please don't hesitate to pass along any more thoughts.


On 2010-04-30, at 9:43 AM, MarcusT wrote:

> Hi, I've just found your Fluid Demonstration Portal and think it shows great promise, but I am surprised that your Reorderer demos don't include any example of how to persist the reordered elements (and reapply a persisted state), which is surely going to the most likely real-world use of the components.
> I suggest that an inbuilt mechanism (shared between all reorderers) to serialize the state of all reorderable items on the page to a string (which can then be stored in a cookie, sent to a server, etc) should be added, along with corresponding deserialize functionality (i.e. to process a serialized string and set the state of all the reorderable items again). I suggest JSON as a suitable string encoding mechanism, and ideally use of this feature should require a unique ID for each reorderable element, but one could argue that there might be some use in supporting non-ID'd elements simply by following the natural order of the elements within the document (but of course this will cause problems in many situations where the items change position or number over time - i.e. server-side/dynamic output).
> The demos should then be updated to showcase this new functionality by including a button for "persist to cookie" (which store the serialized state into a cookie, which would automatically be loaded and applied when you reload the page to see the items in the same order you left them in), a reset cookie button (for obvious reasons), and one more button "persist to form" which would display the serialized string in a text field so that its format can easily be viewed.
> Finally, if you're not already hosting your library on GitHub then I suggest that you consider doing so to make suggestions/issues/etc much easier to submit and manage, as well as gaining greater visibility/recognition, making it possible to "watch" for updates, encouraging forking, etc.
> Best regards,
> Marcus Tucker
> _______________________________________________
> Infusion-users mailing list
> Infusion-users at fluidproject.org
> http://fluidproject.org/mailman/listinfo/infusion-users

More information about the Infusion-users mailing list