aerogear-controller 1.0.0.Alpha released + proposed roadmap + call for discussion
5 views
Skip to first unread message
Douglas Campos
Jul 14, 2012, 1:57:45 AM7/14/12
to jbos...@googlegroups.com
Hello!
Based on what we had shown before, I've just released[1] the bare minimum that was already done for the lightweight mvc.
Now I really want feedback on the proposed roadmap, and feature ideas (both for the core and for the CDI-based extensions).
Thoughts?
[1]:http://blog.qmx.me/aerogear-controller-alpha-is-out/
-- qmx
Based on what we had shown before, I've just released[1] the bare minimum that was already done for the lightweight mvc.
Now I really want feedback on the proposed roadmap, and feature ideas (both for the core and for the CDI-based extensions).
Thoughts?
[1]:http://blog.qmx.me/aerogear-controller-alpha-is-out/
-- qmx
Pete Muir
Jul 16, 2012, 8:18:16 AM7/16/12
to jbos...@googlegroups.com
Douglas, where would you prefer feedback? Here or on the blog?
Douglas Campos
Jul 16, 2012, 8:21:54 AM7/16/12
to jbos...@googlegroups.com
Either one would be fine, as long there's feedback!
feel free to choose what's easier for you :)
-- qmx
feel free to choose what's easier for you :)
Brian Leathem
Jul 16, 2012, 10:13:54 AM7/16/12
to jbos...@googlegroups.com, Douglas Campos
Great to see progress on this - I look forward to digging in!
Brian
Brian
Pete Muir
Jul 16, 2012, 10:27:01 AM7/16/12
to jbos...@googlegroups.com
Some comments, in no particular order:
* rhetoric is very good
* I like the example
** but could do with a bit of javadoc to aid comprehension
* I'm still concerned about the branding/organisation around this.
** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
** Will aerogear-controller be used in the native client libraries stuff?
* Roadmap
** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
** adding some target dates (e.g. months or quarters) to the roadmap is still needed
* Requirements
** Not sure if you are planning on delivering this separately?
** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
** If you want me to write up a set of initial requirements, extracted from your blog, then say.
* Routes
** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
* Future stuff
** I think path parameters and dispatchers will help a lot
** Extension model is going to be key I think, by the sound of it
** integrating security is definitely going to be key
** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
** a forge plugin for this would be very nice, as would an IDE plugin, to help visualise the routes
On 14 Jul 2012, at 06:57, Douglas Campos wrote:
* rhetoric is very good
* I like the example
** but could do with a bit of javadoc to aid comprehension
* I'm still concerned about the branding/organisation around this.
** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
** Will aerogear-controller be used in the native client libraries stuff?
* Roadmap
** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
** adding some target dates (e.g. months or quarters) to the roadmap is still needed
* Requirements
** Not sure if you are planning on delivering this separately?
** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
** If you want me to write up a set of initial requirements, extracted from your blog, then say.
* Routes
** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
* Future stuff
** I think path parameters and dispatchers will help a lot
** Extension model is going to be key I think, by the sound of it
** integrating security is definitely going to be key
** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
** a forge plugin for this would be very nice, as would an IDE plugin, to help visualise the routes
On 14 Jul 2012, at 06:57, Douglas Campos wrote:
Marius Bogoevici
Jul 16, 2012, 10:52:16 AM7/16/12
to jbos...@googlegroups.com
Hey Douglas,
Excellent stuff! I'll try to send in a more thorough overview later, but here are 2 things that jumped out to me:
a) I find the DSL routing interesting, however I think that we should do more to leverage JAX-RS and even COC-style controller mapping
b) I cannot see any view dispatching from controller methods - URLs seem to map to a controller method/page combo, but I would find it useful to be able to route a particular request to a different view than the default in particular cases
(e.g. wizards, validation,etc.).
I know that b) comes from a Struts/SpringMVC kind of thinking, whereas this draws inspiration from Rails/Play, however, it is a typical feature for users of the MVC pattern (and I find it fits well the request driven model in particular).
Also, plugability of view technologies is critically important, I will want to use my existing JSP pages with something like this.
Excellent stuff! I'll try to send in a more thorough overview later, but here are 2 things that jumped out to me:
a) I find the DSL routing interesting, however I think that we should do more to leverage JAX-RS and even COC-style controller mapping
b) I cannot see any view dispatching from controller methods - URLs seem to map to a controller method/page combo, but I would find it useful to be able to route a particular request to a different view than the default in particular cases
(e.g. wizards, validation,etc.).
I know that b) comes from a Struts/SpringMVC kind of thinking, whereas this draws inspiration from Rails/Play, however, it is a typical feature for users of the MVC pattern (and I find it fits well the request driven model in particular).
Also, plugability of view technologies is critically important, I will want to use my existing JSP pages with something like this.
Jay Balunas
Jul 16, 2012, 7:15:54 PM7/16/12
to jbos...@googlegroups.com, Jay Balunas
Hey Pete, thanks for taking a look at this, a couple of comments inline.
On Jul 16, 2012, at 10:27 AM, Pete Muir wrote:
> Some comments, in no particular order:
>
> * rhetoric is very good
>
> * I like the example
> ** but could do with a bit of javadoc to aid comprehension
>
> * I'm still concerned about the branding/organisation around this.
> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
> ** Will aerogear-controller be used in the native client libraries stuff?
Yes, the client libraries will use the AeroGear-Controller, although perhaps not a 100% dependency some of the advanced functionality will need it. Most likely the security integration work that Bruno has been looking into from any client. The controller will also be integral to the JavaScript client library for mobile web, and likely cordova support as well.
At this point AeroGear Controller is a sub-project of AeroGear, which seems appropriate to me. The Aerogear project needs this now, Doug has been doing the research/development to this point, why move it outside?
>
> * Roadmap
> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
> ** adding some target dates (e.g. months or quarters) to the roadmap is still needed
+1 Doug and I have discussed this as well.
>
> * Requirements
> ** Not sure if you are planning on delivering this separately?
> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
>
> * Routes
> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
>
> * Future stuff
> ** I think path parameters and dispatchers will help a lot
> ** Extension model is going to be key I think, by the sound of it
> ** integrating security is definitely going to be key
Bruno is actually integrating the latest DeltaSpike security with it in a branch now to see how this is working.
> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
> ** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
> ** a forge plugin for this would be very nice, as would an IDE plugin, to help visualise the routes
Exactly! A lot of what you mention here has been discussed in our team meetings, project site, and other spots (tooling, JAX-RS integration, etc...). I think a forge/tooling for this is critical, as is testing integration.
On Jul 16, 2012, at 10:27 AM, Pete Muir wrote:
> Some comments, in no particular order:
>
> * rhetoric is very good
>
> * I like the example
> ** but could do with a bit of javadoc to aid comprehension
>
> * I'm still concerned about the branding/organisation around this.
> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
> ** Will aerogear-controller be used in the native client libraries stuff?
At this point AeroGear Controller is a sub-project of AeroGear, which seems appropriate to me. The Aerogear project needs this now, Doug has been doing the research/development to this point, why move it outside?
>
> * Roadmap
> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
> ** adding some target dates (e.g. months or quarters) to the roadmap is still needed
>
> * Requirements
> ** Not sure if you are planning on delivering this separately?
> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
>
> * Routes
> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
>
> * Future stuff
> ** I think path parameters and dispatchers will help a lot
> ** Extension model is going to be key I think, by the sound of it
> ** integrating security is definitely going to be key
> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
> ** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
> ** a forge plugin for this would be very nice, as would an IDE plugin, to help visualise the routes
Douglas Campos
Jul 16, 2012, 7:41:54 PM7/16/12
to jbos...@googlegroups.com
On Jul 16, 2012, at 11:27 AM, Pete Muir wrote:
> Some comments, in no particular order:
>
> * rhetoric is very good
>
> * I like the example
> ** but could do with a bit of javadoc to aid comprehension
https://issues.jboss.org/browse/AEROGEAR-309
> * I like the example
> ** but could do with a bit of javadoc to aid comprehension
>
> * I'm still concerned about the branding/organisation around this.
> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
> ** Will aerogear-controller be used in the native client libraries stuff?
>
> * Roadmap
> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
https://issues.jboss.org/browse/AEROGEAR-310
> * I'm still concerned about the branding/organisation around this.
> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
> ** Will aerogear-controller be used in the native client libraries stuff?
>
> * Roadmap
> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
> ** adding some target dates (e.g. months or quarters) to the roadmap is still needed
https://issues.jboss.org/browse/AEROGEAR-311
>
> * Requirements
> ** Not sure if you are planning on delivering this separately?
> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
https://issues.jboss.org/browse/AEROGEAR-312
> * Requirements
> ** Not sure if you are planning on delivering this separately?
> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
Just comment on 312 about what format you want, more specifically please
>
> * Routes
> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
The focus here is on **not** using annotations, at least for now - it might not make sense for us JavaEE devs, but we're targeting another market (rails, play, springmvc & friends)
> * Routes
> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
Note that this is not set on stone, it could be added later for sure.
> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
one class for page? Mind to elaborate?
> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
We have several options here, I restrained myself from deciding for one (the easiest way is to return a "Model/View" object with all the attributes you want, but this would be too springmvc-y)
> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
https://issues.jboss.org/browse/AEROGEAR-306
> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
I want this to be provided from JAX-RS/RESTEasy, but without the annotations, so 100% intentional
>
> * Future stuff
> ** I think path parameters and dispatchers will help a lot
> ** Extension model is going to be key I think, by the sound of it
> ** integrating security is definitely going to be key
https://issues.jboss.org/browse/AEROGEAR-305
> * Future stuff
> ** I think path parameters and dispatchers will help a lot
> ** Extension model is going to be key I think, by the sound of it
> ** integrating security is definitely going to be key
> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
IMHO we need both, I'm just focusing on making what we have **today** working
> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
That said, I loved the "jaml" idea. Where do we track this? Does anyone has started a github project for it? (I'm studying MVEL)
> ** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
> ** a forge plugin for this would be very nice,
https://issues.jboss.org/browse/AEROGEAR-313
> as would an IDE plugin, to help visualise the routes
https://issues.jboss.org/browse/AEROGEAR-314
(I'm -0 for this, but let's discuss on the ticket)
>
> On 14 Jul 2012, at 06:57, Douglas Campos wrote:
>
>> Hello!
>>
>> Based on what we had shown before, I've just released[1] the bare minimum that was already done for the lightweight mvc.
>>
>> Now I really want feedback on the proposed roadmap, and feature ideas (both for the core and for the CDI-based extensions).
>>
>> Thoughts?
>>
>> [1]:http://blog.qmx.me/aerogear-controller-alpha-is-out/
>>
>> -- qmx
>>
>
Douglas Campos
Jul 16, 2012, 8:07:33 PM7/16/12
to jbos...@googlegroups.com
On Jul 16, 2012, at 11:52 AM, Marius Bogoevici wrote:
> Hey Douglas,
>
> Excellent stuff! I'll try to send in a more thorough overview later, but here are 2 things that jumped out to me:
>
> a) I find the DSL routing interesting, however I think that we should do more to leverage JAX-RS
> ... COC-style controller mapping
Marius, mind to comment at https://issues.jboss.org/browse/AEROGEAR-316 with more ideas?
> b) I cannot see any view dispatching from controller methods - URLs seem to map to a controller method/page combo, but I would find it useful to be able to route a particular request to a different view than the default in particular cases
> (e.g. wizards, validation,etc.).
>
> I know that b) comes from a Struts/SpringMVC kind of thinking, whereas this draws inspiration from Rails/Play, however, it is a typical feature for users of the MVC pattern (and I find it fits well the request driven model in particular).
Exactly - I just didn't wanted to decide this for myself ;)
> I know that b) comes from a Struts/SpringMVC kind of thinking, whereas this draws inspiration from Rails/Play, however, it is a typical feature for users of the MVC pattern (and I find it fits well the request driven model in particular).
>
> Also, plugability of view technologies is critically important, I will want to use my existing JSP pages with something like this.
>
> On 2012-07-14, at 1:57 AM, Douglas Campos wrote:
>
>> Hello!
>>
>> Based on what we had shown before, I've just released[1] the bare minimum that was already done for the lightweight mvc.
>>
>> Now I really want feedback on the proposed roadmap, and feature ideas (both for the core and for the CDI-based extensions).
>>
>> Thoughts?
>>
>> [1]:http://blog.qmx.me/aerogear-controller-alpha-is-out/
>>
>> -- qmx
>>
>
Pete Muir
Jul 17, 2012, 10:37:41 AM7/17/12
to jbos...@googlegroups.com, Jay Balunas
On 17 Jul 2012, at 00:15, Jay Balunas wrote:
> Hey Pete, thanks for taking a look at this, a couple of comments inline.
>
>
> On Jul 16, 2012, at 10:27 AM, Pete Muir wrote:
>
>> Some comments, in no particular order:
>>
>> * rhetoric is very good
>>
>> * I like the example
>> ** but could do with a bit of javadoc to aid comprehension
>>
>> * I'm still concerned about the branding/organisation around this.
>> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
>> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
>> ** Will aerogear-controller be used in the native client libraries stuff?
>
> Yes, the client libraries will use the AeroGear-Controller, although perhaps not a 100% dependency some of the advanced functionality will need it. Most likely the security integration work that Bruno has been looking into from any client. The controller will also be integral to the JavaScript client library for mobile web, and likely cordova support as well.
>
> At this point AeroGear Controller is a sub-project of AeroGear, which seems appropriate to me. The Aerogear project needs this now, Doug has been doing the research/development to this point, why move it outside?
Different thread, but I'm seeing something like: "A set of libraries to allow interaction between various clients (e.g. HTML5, native iOS, native Android) and a Java EE application server, using JAX-RS/MVC". In that case, the Aerogear branding makes sense.
>
>>
>> * Roadmap
>> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
>> ** adding some target dates (e.g. months or quarters) to the roadmap is still needed
>
> +1 Doug and I have discussed this as well.
>
>>
>> * Requirements
>> ** Not sure if you are planning on delivering this separately?
>> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
>> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
>>
>> * Routes
>> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
>> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
>> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
>> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
>> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
>>
>> * Future stuff
>> ** I think path parameters and dispatchers will help a lot
>> ** Extension model is going to be key I think, by the sound of it
>> ** integrating security is definitely going to be key
>
> Bruno is actually integrating the latest DeltaSpike security with it in a branch now to see how this is working.
>
>> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
>> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
>> ** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
>> ** a forge plugin for this would be very nice, as would an IDE plugin, to help visualise the routes
>
> Exactly! A lot of what you mention here has been discussed in our team meetings, project site, and other spots (tooling, JAX-RS integration, etc...). I think a forge/tooling for this is critical, as is testing integration.
Pete Muir
Jul 17, 2012, 10:52:50 AM7/17/12
to jbos...@googlegroups.com
On 17 Jul 2012, at 00:41, Douglas Campos wrote:
>
> On Jul 16, 2012, at 11:27 AM, Pete Muir wrote:
>
>> Some comments, in no particular order:
>>
>> * rhetoric is very good
> thanks ;)
>>
>> * I like the example
>> ** but could do with a bit of javadoc to aid comprehension
> https://issues.jboss.org/browse/AEROGEAR-309
>>
>> * I'm still concerned about the branding/organisation around this.
>> ** If we're simply using aerogear-controller as a placeholder, and we're all aware this needs addressing rsn, then you can ignore this
>> ** I would prefer we brand stuff by stack, eg. how we have Errai and RichFaces, each of which represent a view layer stack. To me it makes most sense to have an HTML+REST stack project.
>> ** Will aerogear-controller be used in the native client libraries stuff?
>>
>> * Roadmap
>> ** typically we use the release candidate as "feature complete, testing for .Final", so I would suggest making 1.0.0.Beta -> 1.0.0.Beta1 and 1.0.0.CR -> 1.0.0.Beta2 and 1.0.0.Final -> 1.0.0.CR1
> https://issues.jboss.org/browse/AEROGEAR-310
>> ** adding some target dates (e.g. months or quarters) to the roadmap is still needed
> https://issues.jboss.org/browse/AEROGEAR-311
>>
>> * Requirements
>> ** Not sure if you are planning on delivering this separately?
>> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> https://issues.jboss.org/browse/AEROGEAR-312
>> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
> Just comment on 312 about what format you want, more specifically please
>>
>> * Routes
>> ** I'm not sure I really like extending the AbstractRoutingModule, what about doing something like Arquillian does, with an annotated @Routing method or similar?
> The focus here is on **not** using annotations, at least for now - it might not make sense for us JavaEE devs, but we're targeting another market (rails, play, springmvc & friends)
>
> Note that this is not set on stone, it could be added later for sure.
>> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
> one class for page? Mind to elaborate?
>> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
> We have several options here, I restrained myself from deciding for one (the easiest way is to return a "Model/View" object with all the attributes you want, but this would be too springmvc-y)
>> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
> https://issues.jboss.org/browse/AEROGEAR-306
>> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
> I want this to be provided from JAX-RS/RESTEasy, but without the annotations, so 100% intentional
>>
>> * Future stuff
>> ** I think path parameters and dispatchers will help a lot
>> ** Extension model is going to be key I think, by the sound of it
>> ** integrating security is definitely going to be key
> https://issues.jboss.org/browse/AEROGEAR-305
>> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
>> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
> IMHO we need both, I'm just focusing on making what we have **today** working
>
> That said, I loved the "jaml" idea. Where do we track this? Does anyone has started a github project for it? (I'm studying MVEL)
How pluggable is the haml impl you are using? Can we extract or reuse the structure parsing, but replace the expression parsing/evaluation?
>
>> ** I think we need to do much deeper JAX-RS integration than I'm seeing today, and that this should be much further up the roadmap (see above)
> We're on the same page - I started talking with bburke about how to programmatically define JAX-RS endpoints, and there's no object model configuration support on RESTEasy - I'll be working on this, so both projects can benefit from it.
>> ** a forge plugin for this would be very nice,
> https://issues.jboss.org/browse/AEROGEAR-313
>> as would an IDE plugin, to help visualise the routes
> https://issues.jboss.org/browse/AEROGEAR-314
> (I'm -0 for this, but let's discuss on the ticket)
Douglas Campos
Jul 17, 2012, 12:31:41 PM7/17/12
to jbos...@googlegroups.com
On Jul 17, 2012, at 11:52 AM, Pete Muir wrote:
>>> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
>> one class for page? Mind to elaborate?
>
> I would have expected the Home class to relate to home.jsp.
I really would like a more concrete example.
>
>>> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
>> We have several options here, I restrained myself from deciding for one (the easiest way is to return a "Model/View" object with all the attributes you want, but this would be too springmvc-y)
>
> Yeah, I guess you can return some sort of struct. This seems pretty ugly to me, as Java has such poor support for structs.
>>> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
>> https://issues.jboss.org/browse/AEROGEAR-306
>>> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
>> I want this to be provided from JAX-RS/RESTEasy, but without the annotations, so 100% intentional
>
> Sorry, what is "this" in your reply?
>>> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
>>> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
>> IMHO we need both, I'm just focusing on making what we have **today** working
>>
>> That said, I loved the "jaml" idea. Where do we track this? Does anyone has started a github project for it? (I'm studying MVEL)
>
> No, I just invented it ;-)
> How pluggable is the haml impl you are using? Can we extract or reuse the structure parsing, but replace the expression parsing/evaluation?
-- qmx
Pete Muir
Jul 17, 2012, 12:34:44 PM7/17/12
to jbos...@googlegroups.com
On 17 Jul 2012, at 17:31, Douglas Campos wrote:
>
> On Jul 17, 2012, at 11:52 AM, Pete Muir wrote:
>
>>>> ** I don't really quite like/get the design of using methods on classes to refer to page. I was expecting a class to map to a page.
>>> one class for page? Mind to elaborate?
>>
>> I would have expected the Home class to relate to home.jsp.
>
>
> Do you mean a one-method-class per page? This would end in tons of classes for a bigger app.
> I really would like a more concrete example.
I'm not saying I have a better design, just that you broke the principal of least surprise for me at least ;-)
>
>>
>>>> ** I can see how a method can return an object, like Car, and then you can reference it in the view, but then I don't see how I can return >1 object, which any non trivial example is going to want to do. I suspect this is related somehow to the previous point ;-)
>>> We have several options here, I restrained myself from deciding for one (the easiest way is to return a "Model/View" object with all the attributes you want, but this would be too springmvc-y)
>>
>> Yeah, I guess you can return some sort of struct. This seems pretty ugly to me, as Java has such poor support for structs.
> Agreed, but we need to find something "less ugly", and I don't want to decide this unilaterally, I'm sure someone else has a better idea ;)
>
>>>> ** I think I would have found it clearer if the Routes concentrated on routing, and then delegated the actual processing of requests to JAX-RS (it kinda feels like we are reinventing this api), and i think again this might make the above a bit clearer.
>>> https://issues.jboss.org/browse/AEROGEAR-306
>>>> ** You seem to have gone to some lengths to keep the controller class free of marshalling, i'm not sure if this is intentional? But I would question this, as it's not really a reusable class, so we don't gain anything through this
>>> I want this to be provided from JAX-RS/RESTEasy, but without the annotations, so 100% intentional
>>
>> Sorry, what is "this" in your reply?
> Marshalling, I want to defer "this" to RESTEasy.
I think it's hard to discuss this much more until we see what the RESTEasy integration starts to look like.
>
>>>> ** do we need a generic extension API for the routing DSL? Otherwise, I don't know how we decide what is in / out...
>>>> ** still very mixed opinions on whether we should port haml 1:1 or whether we are better doing "jaml" (;-)) - i.e. haml but supporting embedding Java-esque syntax, courtesy of MVEL?
>>> IMHO we need both, I'm just focusing on making what we have **today** working
>>>
>>> That said, I loved the "jaml" idea. Where do we track this? Does anyone has started a github project for it? (I'm studying MVEL)
>>
>> No, I just invented it ;-)
> Here's your one million check ;) - jokes aside, this is a very interesting idea, let's not forget it.
>
>> How pluggable is the haml impl you are using? Can we extract or reuse the structure parsing, but replace the expression parsing/evaluation?
> It's the Ruby canonical impl (https://github.com/haml/haml), running via JRuby, on a servlet filter.
But I suspect the structure parsing isn't too hard.
Bruno Oliveira
Jul 17, 2012, 12:44:13 PM7/17/12
to jbos...@googlegroups.com
Hi guys,
Yesterday I’ve migrated the aerogear controller demo with DeltaSpike 0.2 into a new branch with the latest release of aerogear-controller (https://github.com/aerogear/aerogear-controller-demo/tree/deltaspike).
Now the next steps are to find out the best approach to integrate DS into aerogear-controller and solve https://issues.jboss.org/browse/AEROGEAR-305. The client libraries will be the other side of the puzzle related with the progress of that JIRA.
- Bruno
--
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
Pete Muir
Jul 19, 2012, 11:49:50 AM7/19/12
to jbos...@googlegroups.com
On 17 Jul 2012, at 00:41, Douglas Campos wrote:
>> * Requirements
>> ** Not sure if you are planning on delivering this separately?
>> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> https://issues.jboss.org/browse/AEROGEAR-312
>> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
> Just comment on 312 about what format you want, more specifically please
https://issues.jboss.org/browse/AEROGEAR-312?focusedCommentId=12706814#comment-12706814
>> ** Not sure if you are planning on delivering this separately?
>> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> https://issues.jboss.org/browse/AEROGEAR-312
>> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
> Just comment on 312 about what format you want, more specifically please
To me, I can now see quite clearly the direction this is going in :-)
Other people?
Jason Porter
Jul 19, 2012, 12:49:31 PM7/19/12
to jbos...@googlegroups.com
Sounds good to me.
If we're supporting tilt though, do we need to support anything else? If we're going to be running this on jruby (is there a java version of tilt?) we should be able to create a JSP tilt extension.
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Douglas Campos
Jul 19, 2012, 1:59:38 PM7/19/12
to jbos...@googlegroups.com
On Jul 19, 2012, at 1:49 PM, Jason Porter wrote:
> Sounds good to me.
>
> If we're supporting tilt though, do we need to support anything else? If we're going to be running this on jruby (is there a java version of tilt?) we should be able to create a JSP tilt extension.
(I'm packaging the "haml" gem inside the aerogear-haml project during build)
I wouldn't commit for shipping tilt exactly because of the big size this can become (jruby is 10+megs by itself)
>
> On Thu, Jul 19, 2012 at 9:49 AM, Pete Muir <pm...@redhat.com> wrote:
>
> On 17 Jul 2012, at 00:41, Douglas Campos wrote:
>
> >> * Requirements
> >> ** Not sure if you are planning on delivering this separately?
> >> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> > https://issues.jboss.org/browse/AEROGEAR-312
> >> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
> > Just comment on 312 about what format you want, more specifically please
>
> https://issues.jboss.org/browse/AEROGEAR-312?focusedCommentId=12706814#comment-12706814
>
> To me, I can now see quite clearly the direction this is going in :-)
>
> Other people?
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
-- qmx
> On Thu, Jul 19, 2012 at 9:49 AM, Pete Muir <pm...@redhat.com> wrote:
>
> On 17 Jul 2012, at 00:41, Douglas Campos wrote:
>
> >> * Requirements
> >> ** Not sure if you are planning on delivering this separately?
> >> ** I would still like to see a more formal exposition of the requirements, I can start to see them from your blog post, but really only from reading between the lines, and guessing. As previously discussed, as we have disparate groups interested in this, it's necessary to pursue a more formal approach here.
> > https://issues.jboss.org/browse/AEROGEAR-312
> >> ** If you want me to write up a set of initial requirements, extracted from your blog, then say.
> > Just comment on 312 about what format you want, more specifically please
>
> https://issues.jboss.org/browse/AEROGEAR-312?focusedCommentId=12706814#comment-12706814
>
> To me, I can now see quite clearly the direction this is going in :-)
>
> Other people?
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
Reply all
Reply to author
Forward
0 new messages