3:55 p.m.
On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <lucas.holmquist(a)gmail.com> wrote:
I agree with the separation. Having it connect to a separate data
layer makes sense. Then they can use the data layer without pipeline if they wanted to
get it another way.
Exactly
it seems that each Library(maybe not the right word) should do one thing and do it
awesome!
We don't want to just recreate backbone Models, or any other other Model part of a
framework for that matter.
I know in my development, i just want to get the data from the backend and manipulate it
on my own.
The only question i have is how the separation would relate to the sync process? Would
the user then have to use both pipeline and data thing to keep front/back end in sync?
That's a good question. In order to keep them separate, yes they would need both to
have AeroGear handle the syncing or they would have to do sync on their own.
On a side note, I am planning on adding different build options into the grunt build so
that people can pick and choose what pieces they want and create a custom build.
Eventually, it would be nice to have a little web app that did that for them by checking a
few boxes and clicking download as well but this is all future stuff.
-Luke
On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <kris(a)redhat.com> wrote:
Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts both on what
they think of the library so far, and where they would like to see it go in the future.
Please take a look at http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/
and provide any feedback on the current roadmap that you may have.
Also, and more to the subject of this e-mail, I want to discuss the separation of
concerns between the different pieces of AeroGear.js and what should be handled where. I
bring this up because as I move forward with Pipeline and the other components of the
library, I find myself implementing things where they may not belong. Specifically, I have
started creating a filter method in the REST adapter for pipeline. I have started to think
that this is not where that method belongs and in fact, the storage of data in the
pipeline object at all I think was a mistake. I think Pipeline should be just that, a
pipeline for data to move between the client and server and should not be a place where
data is managed or manipulated.
This is where some sort of data management piece of the lib comes in - no clever name yet
:). I would like to see Pipeline handle the transport of data, whether that be with REST,
websockets or what ever, but then just hand the data off to the app to do what it wants.
Then, we can support a connection between Pipeline and this data management piece so that
if the user wants help with data management including storage in memory, session storage,
local storage, web sql, IndexedDB, files, etc. they could pass an instance of the data
manager to Pipeline and say put the data here when you get it or take it from here when
you send it, etc.
I hope this novel I just wrote makes sense but please feel free to ask questions, make
comments and suggestions, tell me I'm an idiot, what ever. If people seem on board
with this, I would like to get a basic memory based storage system similar to what is in
Pipeline now, moved out into it's on section of the library in conjunction with
working on aerogear-auth.js for M6.
Thanks,
Kris
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev