Planning for next release

[Rizqi Ahmad]

Hi guys,

i am planning for next releases.

what I am planning right now is:

- optimization. Binding large amount of data should be faster or at
least responsive (asynchronous)
- support for external datasource. Separating data from view. So the
chain will link data from datasource. (Real Data Binding)
- Binding to the server. Automatic data synchronization, request &
posting data. (For this I will start with couchdb, if someone has
experiences with Rest based mvc framework like Ruby on Rails please
contact me)

What do you think? Should I make chain.js library independent?

feedback please

Thank You

[Vincent Pérès]

Hello Rizqi,

Great job, last version is realy quick !
My need is more 'user interface' (but maybe I forget some point from
the documentation) :
when I replace elements with Chain, I would like to add effects like
that : http://ui.jquery.com/repository/real-world/range-interface/

Anyway, I'm currently working on rails + jquery + chain, if you have
any questions about rails, mail me !

Thanks,
Vincent

[Rizqi Ahmad]

Hi vincent,

do you mean slider widget?

[Vincent Pérès]

Sorry, I mean effects on my Chain items when I remove or replace them
(fade out, pop etc.)

[Rizqi Ahmad]

ok, I think it is still compatible with jquery effects. May be I could
put some event handlers to items, such as remove, etc.

[Mathew Byrne]

Hey Rizqui,

• Optimization is always a win for any library, especially client side
ones. The quicker the better!

• This is a brilliant idea, I was going to suggest something like
this. Currently it can be a chore when dealing with data used in
multiple places on a single document, a separate datastore would
hopefully alleviate this. I assume chain.js would supply this
datastore?

• I think chainjs should remain server agnostic as much as possible (I
usually work with a PHP backend), as long as the REST api that chainjs
would expect was clearly defined I don't think this will be an issue.
Server synchronization is definitely another win. At the moment I have
been manually updating the server and my chain.js items at the same
time.

So basically, thumbs up. I think you're definitely on the right path
for the next release.

Cheers

[Rusco]

Well, if Santa Claus would ask me I would give him the following
answers:
-> stick to JQuery, even Micro$oft does that (If you want to be lib
agnostic you would use Pure anyhow).
-> please have a look at the jlinq plugin at: http://www.hugoware.net/jlinq
, some features like "where" are much less intuitive in chain
-> I see the need and the advantage of interface.js integration, the
problem I see is that there is also the jquery-ui world and there is
the danger that you end up reinventing the wheel.

Chain Rocks !
Rusco.

> > Thank You- Ocultar texto citado -
>
> - Mostrar texto citado -

[Relleum]

Hey Rizqi, great job on the new release. I'd love to try it, but I
have a heavily modified version of your code and it will take a while
to implement version 0.2. I also wrote a blog entry about the
changes I made, so please check it out:

http://samuelmueller.com/post/2008/10/20/Client-side-templates-using-ASPNET-JQuery-Chain-and-TaffyDB.aspx

[Rizqi Ahmad]

Hi Sam,

hehe, the problem you pointed in your blog is the one that i going to
solve in 0.3

but I am not going to replace DOM with innerHTML, since as you said it
doesn't solve the problem entirely, and it would break compatibility
with interaction.js. I would rather create a datasource object that
holds the "master view" and maintain the "binding" to chained element
(remind that chain.js is not just plain templating engine, but rather
a binding & data management").

Rather than taffyDB i am going to create chain.js own datasource
object that mantain the binding to the item, so you can link your
element to a certain "collection"(view) in datasource, similar to
linking to other chain element. As design inspiration I take the WPF
data binding solution http://msdn.microsoft.com/en-us/library/ms752347.aspx

What I want to achieve with datasource is to create a smart object
that at the same time maintain synchronity between server and client
(since data come in most of cases from server) and to the view (chain
object).

What I meant by smart is, that the view just have to create small
amount of items, and these items would be only created ONCE, then the
datasource bind them to the current collection/view. This collection
is a paged collection, which mean, if page is changed, the items would
NOT REGENERATED but only RELINKED to the next items. Using this, we
can create smart scroller, that means that we could modify the
scrollbar so that it doesn't scroll, but change the offset/page of the
datasource.

The advantage of this method is the small footprint since only small
amount of DOM objects would be generated and also we could create
dynamic data loading like yahoo mail. The Concept would be like this:

(it is a bit simplified, contact me for more detailed concept)
- datasource connect to the server (using Rest API) and request some
amount of data
- in this process datasource also gather some information about the
amount of items available and so on.
- datasource display it on chain object. Chain object create a
scroller that represent the whole data amount.
- To preserve responsibility datasource request more amount of data
than the view
- If user do some narrow scroll the data will displayed at once, since
datasource do some caching
- If user do long scroll (e.g. scroll to the end), datasource would
create dataItem object on the fly but with no real data and with
"loading"flag
- in this time datasource also performs a request for the current data
offset. When the data is available dataItem will get it and update the
view.

using this method it would be very simple to display hunderds to
thousands of data

I hope you understand why I am not really interested on TaffyDB and
why DOM is required. I hope you can see my direction.

Actually I this concept has been floating around my mind since I
designed chain.js for the first time (thats why I am commited to dom).
But I wanted to do it step by step (partly because lack of time) and I
want to produce a well designed & structured code (Well In My Opinion
the current design isn't too bad). So I spent rather more time on
conception than coding.

What do you think about this concept? If there are many who are
interested, perhaps we could discuss it more deeply.

regards, Rizqi Ahmad

On 23 Okt., 09:10, Relleum <sjmuel...@gmail.com> wrote:
> Hey Rizqi, great job on the new release.  I'd love to try it, but I
> have a heavily modified version of your code and it will take a while
> to implement version 0.2.  I also wrote a blog entry  about the
> changes I made, so please check it out:
>

> http://samuelmueller.com/post/2008/10/20/Client-side-templates-using-...

[Relleum]

Rizqi,

In my modified version of your code, interaction still works just fine
(at least the selectables portion does, as I've implemented that). I
only eliminated dom creation for the master object. All other linked
views behave the same way as before, with the exception that the list
was built with innerHTML. Now also keep in mind that innerHTML was
only used in the specific instance of creating the child stubs from
the template, and attaching them to the parrent element. After this
was accomplished, I still loop through the buffered items, instantiate
an item.js instance, and run the element through the builder. The
only difference is I just grab the existing stub element stub by index
that I created earlier on the parent.

But in order for the linked views to be able to bind to a particular
collection in the master items, I needed a different approach. Since
the dom elements were gone, how could I dynamically query the data to
build the collection of hidden items? That is where I used TaffyDB.
But TaffyDB isn't the only solution to the problem, and if you can
build something that allows you to quickly query the collection of
data that you need to link to, then that's great.

But I think with whatever direction you choose, you should strive for
acceptable performance in the scenario where several hundred items (or
even thousands) are pulled down and bound to many views (but not
necessarily displayed all at once). In my current project, this
scenario appeals to me because it is very hard to avoid pulling all
the data down. And I don't think I'm the only one with requirements
like this.

And so I am afraid of sticking with DOM for the master datasource,
because I don't think there is a way to get around the slowness just
yet. This article gives a pretty good (albeit slightly biased)
perspective on DOM speed issues and client side rendering:

http://blog.cornerstonenw.com/2008/09/12/the-dom-is-too-slow-for-client-side-page-rendering/

And by the way, you have coded an excellent series of plugins, and it
is crazy to think what the capabilities will be when performance and a
master datasource is achieved!

--Sam

On Oct 23, 8:10 am, Rizqi Ahmad <raid...@yahoo.de> wrote:
> Hi Sam,
>
> hehe, the problem you pointed in your blog is the one that i going to
> solve in 0.3
>
> but I am not going to replace DOM with innerHTML, since as you said it
> doesn't solve the problem entirely, and it would break compatibility
> with interaction.js. I would rather create a datasource object that
> holds the "master view" and maintain the "binding" to chained element
> (remind that chain.js is not just plain templating engine, but rather
> a binding & data management").
>
> Rather than taffyDB i am going to create chain.js own datasource
> object that mantain the binding to the item, so you can link your
> element to a certain "collection"(view) in datasource, similar to
> linking to other chain element. As design inspiration I take the WPF

> data binding solutionhttp://msdn.microsoft.com/en-us/library/ms752347.aspx

[Rizqi Ahmad]

Hmm, I think you don't really get what I want to achieve with
Datasource. Using Datasource all the item will resides in an
javascript array (just as in Taffy), and a small part of them that is
viewed will be bound to linked chain element. If you change the
collection, the dom element will just be rebound to the other data
(please read my previous post again).

There is no rerendering DOM. And it will take care of all requests to
the server. The Datasource will be what you called "Master Datasource"
and there will be no DOM.

TaffyDB will be useless if you have thousands data in your record.
There is no need for database in clientside. Datasource will not be a
DB like Taffy, since clientside sorting and filtering isn't effective.
You are not going to fetch all data in your record to your client
right? Datasource will be a bridge between chain.js and the server.

> http://blog.cornerstonenw.com/2008/09/12/the-dom-is-too-slow-for-clie...

[Rizqi Ahmad]

By the way if you are planning to fork chain, please use the V0.2, it
has less bugs and better documented

[Relleum]

Rizqi,

Ok, so I think we are on the same page if there is no dom for the

datasource. I misunderstood when you said:

"I hope you understand why I am not really interested on TaffyDB and
why DOM is required. I hope you can see my direction. "

That line made me think you were still interested in correlating each
data item in the datasource with a dom object.

But I am curious, how do you plan on the datasource querying the
collections that other views are bound to? Currently, I believe you
use attribute selectors like .children('.chain-item:visible'), but of
course this is not possible with no dom element.

[Rizqi Ahmad]

Ah ok,

I am saying that because I thought you are going to replace DOM with
innerHTML and making chain work like "PURE".

There are two possibility. Either we could create array containing the
collection, or we could create extra properties like hidden=true, etc.