October 2012 - aerogear-dev - Jboss List Archives

by Kris Borchers

Hey all, Just wanted to let you know what I am working on right now. It is very early but Matthias loves e-mail so I thought I would throw this out there. Basically, right now all I am doing is working on keeping track of the status of data in DataManager. Assuming a new dataSync setting is set to true, these are the things I am planning. New record is added to store, status is set to NEW and a UUID is generated Record is updated, status is set to MODIFIED Record is removed, status is set to REMOVED (data is not actually removed, future will need to keep storage limits in mind) Add a new sync method that will run through the data and sync with the server. Assumes client is data of record for now during development until we can determine a strategy for informing the client how the server tracks data status and how it should be informed that this data is being synced This brings us back to the discussion about sending metadata to the client on first app load. That metadata could inform the client of the sync strategy There's probably more to this but these are my original thoughts right now. Kris

13 years, 3 months

4
6
0 / 0

Pipeline jsonp

by Lucas Holmquist

Hi, i've started to add jsonp support to aerogear.js pipeline and i wanted to get some feedback that i'm on the right track i have a example project here : https://github.com/lholmquist/WoWAerogear those of you with yeoman installed can type "yeoman build" then "yeoman server", you might be able to get away with just the second command. There are 2 requests, the first using jQuery, so i had a baseline, and the second is with a modified version of aerogear.js pipeline.add( { ……. settings: { ………... jsonp: true, callback: "myCallback" } } ); I think declaring it during the creation makes sense. Being able to override the jsonpCallback would add a layer of security for when the server defines the callback, I not sure if this should be put into a jsonpSettings:{ } or leave it were it is i only tested read atm, just wanted to get some feedback first -Luke

13 years, 3 months

1
0
0 / 0

PicketBox branch

by Bruno Oliveira

Hi guys, just to let you know the 'picketbox' branch from https://github.com/aerogear/TODO was merged against 'master' and the branch was deleted to avoid mistakes. Now all the latest changes are located on **master**. Thanks. -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile

13 years, 3 months

2
1
0 / 0

Meeting minutes for 2012-10-09

by Douglas Campos

Howdy Here are the meeting notes :) https://github.com/aerogear/collateral/blob/master/mtg-notes/20121009-tea... -- qmx

13 years, 3 months

1
0
0 / 0

Android roadmap review

by Glen Daniels

Hi team, If you would (especially Marko / Daniel), please check out the Android roadmap at: https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1... Comments / issues / thoughts greatly appreciated. Thanks! --Glen

13 years, 3 months

5
9
0 / 0

[JS Doc] feedback on the new JS-Doc

by Matthias Wessendorf

Hi Kris, overall I like the new JS doc (see [1]). Looks pretty nice! However, here is some feedback on the new JS API doc! * http://staging.aerogear.org/docs/specs/aerogear-js/AeroGear.html - add/remove/ajax: These are internal helpers/utilities, right? Not sure if that should be exposed... I think the 'isArray' is a bit different => I can see that some END-USER finds 'AeroGear.isArray(argument)' pretty useful! (compared to something like AeroGear.ajax(...), where you already need to pass in an AeroGear object) * On the different adapters: Regarding their privileged functions => Do we want to expose/document the privileged methods? Or 'just' the public methods? Fixed a little typo: https://github.com/aerogear/aerogear-js/commit/3ed416af824d2b398a7db8b276... Added a PR for two very simple fixes on the JS lib: https://github.com/aerogear/aerogear-js/pull/6 Greetings, Matthias [1] http://staging.aerogear.org/docs/specs/aerogear-js/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

13 years, 3 months

2
8
0 / 0

0.0.4.M6 Snapshot - Error Handling & Controller

by Daniel Bevenius

Hi everyone! We have pushed https://issues.jboss.org/browse/AEROGEAR-426, which means that you are now able to specify error routes to handle exceptions. For example, you can now specify an error route as follows: route() .on(AeroGearSecurityException.class) .to(Error.class).security(); If any of the routes following throws an AeroGearSecurityException, the above error route will be used to handle it. You can specify as many exceptions like the one above as you like. You can also specify multiple exceptions in the on() method, which will all be handled by the same error route: route() .on(CustomException.class, OtherException.class) .to(Error.class).log(); If you want a general error route for all of your routes, you can specify one like this: route() .on(CustomException.class, OtherException.class) .to(Error.class).log(); route() .on(Exception.class) .to(Error.class).index(); At the moment this order might not be intuitive (I'm to blame for this) and there is JIRA (https://issues.jboss.org/browse/AEROGEAR-522) that suggest that the more general exception should be at the top. Lastly, if you don't specify any error route, a default one will used. We are currently working on making this as attractive as possible but at the moment it is very basic. For a real code example: https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main... Try it out: https://github.com/aerogear/aerogear-controller-demo http://errorroutes-danbev.rhcloud.com/aerogear-controller-demo/ What's missing? - As mentioned the order of error routes should probably be reversed (https://issues.jboss.org/browse/AEROGEAR-522) - Currently only GET request are supported (https://issues.jboss.org/browse/AEROGEAR-523) - Support for REST clients (https://issues.jboss.org/browse/AEROGEAR-515) - Default error page - Support for returning a different exception then the one that is thrown inside of the route (https://issues.jboss.org/browse/AEROGEAR-527)

13 years, 3 months

3
2
0 / 0

Ajax usage (aerogear.ajax VS jquery.ajax)

by Matthias Wessendorf

Hi, I was looking at the TODO app ([1]) and noticed that with the 'auth module' the APP DEV has to specify 'contentType' and 'dataType' for the login/register API calls. Not sure, but isn't that a bit cumbersome? This is not the case for any calls on the 'pipe' API, since it is using the aerogear.ajax util (see [2]), which applies the above 'contentType' and 'dataType' as default (see [3]), which is nice! The 'auth rest adapter', however is directly using the jQuery.ajax without applying the same defaults (see [4]). Perhaps we should apply the 'contentType' and 'dataType' default values for something like login or register as well? Thanks! Matthias [1] https://github.com/aerogear/TODO/blob/picketbox/client/src/main/webapp/js... [2] https://github.com/aerogear/aerogear-js/blob/master/src/pipeline/adapters... [3] https://github.com/aerogear/aerogear-js/blob/master/src/utilities/aerogea... [4] https://github.com/aerogear/aerogear-js/blob/master/src/authentication/ad... -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

13 years, 3 months

1
3
0 / 0

[AeroGear.js] Roadmap

by Matthias Wessendorf

Hi (Kris), looked at the roadmap. Overall it looks good. Is the following item still scheduled for the M1 of the JS lib? UUID Generation and data status tracking in preparation for data synchronization Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

13 years, 3 months

2
1
0 / 0

[roadmaps] quick review on roadmaps

by Matthias Wessendorf

Hi, I did a review of some roadmaps before. here are some comments about those that I have not yet reviewed: * Connectivity: zero content: I filed AEROGEAR-524 (see [1]) and assigned it myself, to start defining it. (IMO this needs to be done immediately, after M6 is out). * Controller: The controller roadmap lists some requirements (taken from Doug's blog) and a few use-cases. Currently it is not listing individual milestones and/or CRs. See http://aerogear.org/docs/planning/1.0.0/AeroGearController/ * Persistence: Similar to 'Connectivity' this is something that effects other libraries. I like that it is structured into 'client' and 'server' (same will apply to the 'Connectivity' roadmap), but it also does not list individual milestones/CRs etc. Also some of the items (e.g. REST) are already implemented in several AeroGear libraries. Other (e.g. client validation) is mentioned in out roadmaps (e.g. the JS roadmap has this item listed) Question/Suggestion: Perhaps we spend a bit time about this roadmap in today's meeting? For details see http://aerogear.org/docs/planning/1.0.0/AeroGearPersistence/ * Security Looks good, almost: - iOS =>I need to define iOS specific things (see [2]) - android: lists OAuth - still right ? Ah... one more thing: It talks about 'beta'. AFAIK these are milestone(s), followed by CR, right ? * UMBRELLA roadmap: I guess this item is for Jay => https://issues.jboss.org/browse/AEROGEAR-521 Greetings, Matthias [1] https://issues.jboss.org/browse/AEROGEAR-524 [2] https://issues.jboss.org/browse/AEROGEAR-525 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf

13 years, 3 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

aerogear-dev October 2012