HTML View Responder
by Daniel Bevenius
Hi,
I'm working on AEROGEAR-693 <https://issues.jboss.org/browse/AEROGEAR-693> and
trying to figure out how to implement this in the best way.
At the moment, the default type of ViewResponder is the MvcResponder which
forwards to a JSP page. By default, this means that if you do not specify a
*produces()* method on a route, this is what you'll get.
Now, the media types that are passed to the *produces()* method determine
two things: 1. How to match to Route that is the target of a request,
matching the HTTP *Accept* header. 2. Determining the ViewResponder to be
used.
The issue here is that for both a HTMLResponder and a JSPResponder the
media type would in both cases be*text/html*.
How do we determine which one the users actually has created a view for
(jsp or html page)?
Well, we need some way to differantiate between a route that will respond
with a html view, but which uses a ceratain technique to render the html.
How about a introduce a type, MediaType that looks something like this:
public class MediaType {
public static final String HTML = "text/html";
public static final String ANY = "*/*";
public static final String JSON = "application/json";
private final String mediaType;
private final Class<? extends Responder> responderClass;
private MediaType(final String mediaType, Class<? extends
Responder> responderClass) {
this.mediaType = mediaType;
this.responderClass = responderClass;
}
public String getMediaType() {
return mediaType;
}
public Class<? extends Responder> getResponderClass() {
return responderClass;
}
@Override
public String toString() {
return "MediaType[type=" + mediaType + ", responderClass=" +
responderClass + "]";
}
public static MediaType html() {
return new MediaType(HTML, HtmlViewResponder.class);
}
public static MediaType jsp() {
return new MediaType(HTML, JspViewResponder.class);
}
public static MediaType json() {
return new MediaType(JSON, JsonResponder.class);
}
}
And we could add *html()*, *jsp()*, and *json()* methods to
AbstractRoutingModule, so a route that should be handled by a
HtmlViewResponder would look like this:
route()
.from("/plain")
.on(RequestMethod.GET)
.produces(html())
.to(Html.class).index();
To be backward compatible, if a *produces()* method was not specified it
would be the same as specifying:
.produces(json())
13 years
Cordova Plugin Idea
by Lucas Holmquist
I know we really haven't talked about cordova plugins to much, but i want to just get this thought down so i didn't forget about it.
would it make sense to have a cordova plugin for accessing the core data stuff from our iOS libs, that is once it's ready.
I know cordova has a storage api, but it looks like it is just based on the W3C web storage/web sql specs
i guess i was thinking this is how it would work:
Possibley have an aerogear.js datamanager plugin for the front end that then calls the aerogear ios libs coredata plugin
In JS
var dataManager = AeroGear.DataManager({
name: coreDataStore,
type: CoreData //or something
});
var coreDataStore = dataManager.stores[0];
coreDataStore.read() // this would access the Aerogear ios core data part
I'm not really familiar with core data, so i could be way off base with this idea
-Luke
13 years
AeroGear.js and Bower
by Kris Borchers
So thanks to Luke we have included the latest tag of AeroGear.js in the Bower registry. This allows app developers to include AeroGear in their projects easily through that package management system or via other tools like Yeoman.
The issue is our tags include our entire repo and since Bower basis what it includes in someone's project by what is in the tag, our entire repo gets dropped in the user's project which I'm sure not too many people will be happy about.
I noticed that jQuery has a separate repo for Bower so that only the dist files are included but Luke pointed out that Backbone drops in the whole repo so it doesn't seem like there is a "standard" yet.
I would vote that we create another repo, aerogear/aerogear-js-bower (or something like that) so that our users that use Bower can include the files without worrying about gitignoring our entire repo from the included component.
Thoughts?
13 years
iOS API overhaul - further small changes
by Christos Vasilakis
Hi team,
as part of the API overhaul ticket[1] for the next CR1 release, the following are some small changes in the API that we are proposing.
1.
To be in pair with iOS convention, we are suggesting a change for the config options to be set by properties instead of the current convention.
That it from:
[config name:@"foo"];
to be:
config.name = @"foo";
A ticket has already been opened, see [2]
2.
Change the property URL of the AGPipe object to be an NSURL instead of a String.
That is from:
@property (nonatomic, readonly) NSString *URL
to be:
@property (nonatomic, readonly) NSURL *URL
A ticket has already been opened, see [3]
3.
Per se with iOS convention of construction, rename the current init methods
from:
-(id) init:(NSURL*) baseURL;
+(id) pipeline:(NSURL*) baseURL;
to:
-(id) initWithBaseURL:(NSURL*) baseURL;
+(id) pipelineWithBaseURL:(NSURL*) baseURL;
A ticket has already been opened for this, see [4]
What do you think?
Thanks,
Christos
[1] https://issues.jboss.org/browse/AEROGEAR-763
[2] https://issues.jboss.org/browse/AEROGEAR-751
[3] https://issues.jboss.org/browse/AEROGEAR-764
[4] https://issues.jboss.org/browse/AEROGEAR-766
13 years
