[aerogear-dev] AeroGear.js Separation of Concerns

Matthias Wessendorf matzew at apache.org
Wed Aug 29 04:49:14 EDT 2012


Hi Lucas,

On Tue, Aug 28, 2012 at 10:34 PM, Lucas Holmquist
<lucas.holmquist at gmail.com> wrote:
> I agree with the separation.  Having it connect to a separate data layer
> makes sense.

*any* data layer :)

>  Then they can use the data layer without pipeline if they
> wanted to get it another way.
>
> 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.


can you explain what you mean with that statement ?

>
> 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?
>
> -Luke
>
>
> On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <kris at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf


More information about the aerogear-dev mailing list