Aurora 0.3 MVC Framework Released

Discussions

News: Aurora 0.3 MVC Framework Released

  1. Aurora 0.3 MVC Framework Released (19 messages)

    Aurora is an open-source MVC framework that is aimed at writing configurable, fully object-oriented form controllers using the Spring Framework. The code-base grew out of my experience using Spring's MVC module and slowly developed over several versions into a full-fledged framework that attempts at tackling the most common problems that I had when using Spring MVC and other J2EE web-related issues in general.

    Features:
    Request-Object Mapping
    Avoid working with HTTP-constrained string values or simple primitive types and let Aurora help you take full advantage of your application's domain objects. Using reflection, Aurora can map request values to your domain objects of any type, even user-defined types, and provides a transparent solution to mapping single and multiple references.

    Declarative Form and Validation
    Declaratively set controller settings, form workflow logic and metadata using XML.

    A Generic Programming Model
    Program to the same controller interface for basic, search and wizard-based form types by taking advantage of the strategy pattern. Avoid using delegates or static utility classes to avoid the duplication across your application controllers.

    Elimination of Special Cases
    Avoid common plumbing code such as escaping and unescaping markup characters and entities in text-based input, use HTML checkboxes without considering the null case and process multipart content in the same was as other HTML controls.

    Numerous oppurtunities for extension and pluggability
    Extend server-side controls, form implementations and validators to customize how Aurora works for you.

    I've uploaded the source and binary distributions for Aurora and its sample applications to the SourceForge project page. The Aurora Project team urges everyone to try out the framework and sample applications, read the documentation and post us some feedback.

    Website: http://www.auroramvc.org/
    Support Forums: http://forum.auroramvc.org/
    SourceForge Project: http://sourceforge.net/projects/auroramvc

    Threaded Messages (19)

  2. Aurora 0.3 MVC Framework Released[ Go to top ]

    Have you had much/any feedback from rod and co.? The forums look ominously quiet...
  3. Aurora 0.3 MVC Framework Released[ Go to top ]

    "Have you had much/any feedback from rod and co.? The forums look ominously quiet..."

    Well, the site has only been up for a few days and I don't expect forum activity to escalate until we have some kind of user community established. The forums are there in preparation for that.

    I have talked to Rod and Jeurgon about Aurora and generally the discussion is leading towards Aurora being a related project of Spring. However, I have not heard from them in awhile, so maybe they are just too busy or have decided not to do this. However, I'll give them a few more days to look things over.
  4. Problems with Spring MVC[ Go to top ]

    I'm curious as to what were the problems you found with Spring MVC? Which problems is Aurora offering solutions to?
  5. Problems with Spring MVC[ Go to top ]

    I'm curious as to what were the problems you found with Spring MVC? Which problems is Aurora offering solutions to?
    I investigated migrating a web app to Spring MVC, but after reading through the docs I decided against it. I liked the interface design and the DI support. But it appeared to me that the folks who developed this piece were confusing 'clean and simple design' with 'very little functionality.'

    From the docs, it appeared to me that I would be back to writing some of the tedious plumbing code associated with processing HTML form posts. Ken makes reference to this plumbing code in his release notes, and I expect that this is one of the problems that Aurora is trying to solve.
  6. Interesting but...[ Go to top ]

    It looks interesting, but without some example or tutorials to qualify it, my prediction is that adoption or serious interest will be either slow or just won't happen.

    I know this is very early, and you might have plans to that regard. I just wanted to toss it in anyway. :)
  7. Still Interesting... (and awesome)[ Go to top ]

    There are samples available on the sourceforge download page.
  8. Interesting but...[ Go to top ]

    "It looks interesting, but without some example or tutorials to qualify it, my prediction is that adoption or serious interest will be either slow or just won't happen.

    I know this is very early, and you might have plans to that regard. I just wanted to toss it in anyway. :)"

    The reference documentation is coming along, but it won't be done for awhile. However, there is something like 50 pages of material in there and even for the sections that have not been written, there are still coding and configuration examples all over the place. These were taken from working samples or applications.

    Also, be sure to get the aurora-samples-0.3.zip distribution and deploy the war. There are examples to that show how to do one-to-many and many-to-many request to object mappings, multiparts, using different submission strategies and so on. It's by no means complete (I will add more samples as time goes on), but it is a very good place to start.

    The framework is rather new, but I think we are off to a really good start considering many OSS projects don't have all builds, website, forums, documentation after the first release day that we have had. Things can only get better.
  9. Aurora 0.3 MVC Framework Released[ Go to top ]

    I just read through the documentation. I think you provide good solutions to the main shortcomings of the Spring MVC framework.

    We are currently developing a complex application using Spring and the MVC it provides.
    I think switching to Aurora would bring a major benefit for us.

    When do you think Aurora will be production ready?

    Regards,
    jd
  10. Aurora is already ready![ Go to top ]

    I just read through the documentation. I think you provide good solutions to the main shortcomings of the Spring MVC framework.We are currently developing a complex application using Spring and the MVC it provides.I think switching to Aurora would bring a major benefit for us.When do you think Aurora will be production ready?Regards,jd
    I work with Ken and have already used Aurora for large scale projects and it has been rock solid. There is 98% test coverage (very well tested) and I don't expect any major bugs. I'd give it a try now, there are very simple interfaces to extend it to meet your needs and you can always use Spring's MVC with Aurora's since Aurora is based off Spring. The two can easily co-exist in the same project, but I believe you will find Aurora to just be nicer to use.
  11. Aurora 0.3 MVC Framework Released[ Go to top ]

    "I think switching to Aurora would bring a major benefit for us.

    When do you think Aurora will be production ready?"

    I'm glad to hear that Aurora can help you out with some of your problems.

    As of right now, Aurora is already in production on several applications in my company. It has worked great for us, mainly because we can control everything internally.

    However, I'd imagine that other people will have different requirements than my organization, so I want to be sure that it contains enough controls, validators and configuration options out of the box that will allow everyone to do what they want to do without restriction.

    So to answer your question, Aurora will always be production ready, however it will always grow. The only reason I say that the framework is in "alpha" is that I do expect things to change and I'm not making any promises on backwards compatibility at this point, at least until beta or milestone releases. However, since everything is based on XML, many framework dependancies don't exist and there are only a few interfaces clients depend on, which is a small % of the entire framework.
  12. Aurora 0.3 MVC Framework Released[ Go to top ]

    What does this provide that a WebWork + Spring combo doesn't provide? We use OGNL as our expression language and have built out our type conversion framework around it to be very flexible and to do the kind of plumbing you're talking about automatically, even with complex structures like collections.

    Just curious, as I always like to see what new frameworks are providing and what their differentiator is.
  13. Another request based framework...[ Go to top ]

    While I do think that this is a valid effort to build on top of Spring's "MVC" approach (note MVC is a hijacked term: MVC has to do with Spring or most other request based web ui frameworks about as much as Pascal has with OO), I still feel that this "request based" approach to programming is far inferior to a component and eventbased approach, as advocated by ASP.NET or (much too late) JSF or even the stuff I built on my own.

    Also, component and event based approaches are much more "object oriented" and an event propagation mechanism is much better suited to UI configuration than any "request processing". There is a reason, after all, that event based systems are used in virtually all UI "rich client" environments. Granted you might loose some amount of "view independency" using this but I would usually think that this is a minor glitch as most of the "models" that I see used in typical MVC frameworks (i.e. Spring "command" JavaBeans or Struts "formbeans") are created exclusively for the UI layer in the first place (though not necessarily, one would assume this is bad design, but it is what happens).

    So I am wondering, why not build a decent component framework on top of spring :-)
  14. Another request based framework...[ Go to top ]

    So I am wondering, why not build a decent component framework on top of spring :-)
    Why not use Tapestry with Spring then?
  15. Another request based framework...[ Go to top ]

    Spring integrates well with Tapestry and JSF. I agree that users should consider those 2 options rather than build a new component-based approach on Spring. I haven't had time to look at Aurora--it's a question of lack of time.
  16. Another request based framework...[ Go to top ]

    So I am wondering, why not build a decent component framework on top of spring :-)
    Why not use Tapestry with Spring then?
    Oh absolutely, you can probably use any component framework with Spring but it will be only integrated so far. I don't know how well Tapestry integrates with Spring, but I assume you'd want integration at least for configuration (bean factory) and AOP (intercepting event handlers) to call it "integrated" as opposed to "interfaced".
  17. nicely written[ Go to top ]

    The document is nicely written in
    a conversational style. You may or
    may not agree with the choices made,
    but there are reasons for them.

    Though you really should write class
    and package documentation as you code :-)
  18. Aurora 0.3 MVC Framework Released[ Go to top ]

    Disclaimer - I have not used Aurora, just read the docs. Please correct me if I've got the wrong end of the stick on any of this.

    For command objects, they either have to extend or redefine properties on your domain objects with small variations for holding ids of associated objects for selection controls.

    This was mentioned a few times, and seems to be one of the driving concerns behind this project, and unless I am missing something is obviously untrue. Simply register a custom property editor that translates your request parameter ids into actual instances - that is what property editors are for after all. Now, it would be nice if Spring had a built in collection/list/set property editor that took a collection and pulled out relevant matching instances based on a supplied property name and reflection. At least, that was the strategy we used - but the point is the framework supports this with ease, and does not justify building another framework on top of it with a totally different way of working. Plus, no need to implement any magic interfaces.

    This leads to a problem with Spring's property editor support since it cannot bind false to a Boolean object when the checkbox is not selected. There is actually no solution with Spring Property editors to handle this automatically. Without metadata, or at least some phase where the framework sets the command object properties to their default values before binding, the developer also has to handle this case in the controller code as well.

    Fair comment on the checkbox issue, at least for Spring pre 1.1, but I still see no need for this parricular solution. The common fix for this was to create a generic subclass of databinder that reset any required boolean properties that weren't present. No need to hit controller code, or register any metadata, or deviate at all from the standard spring approach. Plus Spring 1.1 adds built in support to handles this case.


    Lastly, many frameworks try to make the distrinction that multipart content should be handled differently than other request parameters. Perhaps this is due to the fact they request different APIs than regular request values (and even third-party support), but I think frameworks should strive for general solutions. Thus, Aurora provides a solution that treats multipart content like any other request value and makes it even easier to use. Of course, multipart functionality is still built on top of Spring, so you'll have to specify either Commons or COS Multipart upload strategy in your bean factory just as before.


    I honestly don't understand what the problem here is. Spring handles multipart forms totally transparantly using property editors, and if you don't like byte[] properties, write a property editor that maps multipart files to the domain object of your choice.

    I would say there are many valid criticisms of the spring mvc framework, but I don't think the shortcomings pointed out in your docs are compelling. My own pet peeves are:
       * The framework is very low-level, light, and very flexible - this makes it extremely daunting for newcomers (Which one of the umpteen controller classes do I use today?) and makes simple tasks seem more complicated than they actually are.
       * Doing complex tasks sometimes requires you dive into the spring source to understand the whole request/bind/validate lifecycle, and where exactly your operation needs to sit and what template method you will need to override to get the behaviour you want (Particularily with wizard controllers).
       * Spring makes extensive use of the template pattern - which is great until you want to perform an operation at a specific point in the lifecycle, and the only template method available that is called at the right point does not supply you with something you need (eg, the request, response, errors or command object).

    I do agree that the split between simple and wizard forms is annoying and causes refactoring headaches when moving from one to the other, so I will definitely check out Aurora's strategy for declarative controller types.

    Spring MVC is certainly quite sparse and low-level, and is definately a base on which to build a more feature-rich system - but I think it can be done by adding value to the existing mechanisms rather than hiding them with Yet Another MVC Framework. I'll definitely have a closer look at Aurora, but I cant help but wish that the effort had been applied differently, enhancing the existing framework with more pluggable, reusable components that fit in with the existing approach instead of reinventing so much basic infrastructure.
  19. Aurora 0.3 MVC Framework Released[ Go to top ]

    Part of what drove the framework was to try and encapsulate all the variations and make them unified. The best way to do this was XML. Thus validation, forms, controls and all the plug-points are done using XML. This really does limit the disadvantages of the template method pattern since all you need to learn is the various attributes and optional elements to give you the effect that you are looking for. The whole workflow doesn't need to be understand as deeply as Springs either. There are advantages and disadvantages to this approach. Ultimately though, I think saying what you want declaratively is better than hooking, and the entire framework uses this approach consistently all across the board.

    Another one things that Aurora can help you with is the single and multiple object mapping. So if you have a User that contains a UserRole and a collection of UserGroup objects, you can actually get the user object from the FormData interface and just store it to the database in a single line of code since the mapping is done by the framework.

    There was a time, in version 1 (in which the framework was not even isolated at the time) where it was more reliant on Spring MVC than it is now. However, to get the implementation I wanted, I had to sub-class the simple form controller and wizard controller, point them to delegates with their own class hierarchy and then maintain both the sub-classed controllers so that they would behave the same. I tired of this approach and that was the big motivating factory for using the strategy pattern. As application controllers started extending from my framework ones, which in turn extended from Springs, this just caused a huge mess. I mean, if I couldn't extend the framework elegantly as it was, then it does mean that there was a problem with it's dependance on inheritance.

    However, I do agree that I should have contributed to Spring from the start rather than inventing so much. My main point for doing this was to keep it isolated, since so much was self-reliant. And you have to remember, this is the resultant code that grew out of experience over time. I didn't just say one day that I'm going to make a new MVC framework and design it from scratch. I had a lot of code that I liked already there and I just had to package it so other people could hopefully make some use of it.

    My reasons for opening the project up is because I don't want it all to get thrown away (Aurora was just the internal code-name for the project afterall). There is no reason why so much quality code has to be closed so that only a few people can use it. If the only real consequence of all this is that the Spring people add in some new features and make some changes to their MVC in response to what Aurora is doing, then I'm all for that and I'll gladly become a committer to help. I'd rather the Spring team as a whole maintain the new features than me alone, and I think the whole Java community would love having one less framework to learn and deal with. At the end of the day, they can do a lot better than I can. There is just more resoures, more maturity, a larger community and more experience in total than just one man.

    I suggest that you do look at some of the examples and get a feel for it. Once you work with it, you start to see the model better and it feels more confortable. Feel free to pick it apart and say what sucks about it. That's the only way we all know. I have a lot of ideas to extend it too. The framework is still bare-bones and far from finished. There is a lot to do.

    Anyway, hopefully I answered your questions.

    Best Regards,
    Ken Egervari
  20. Spring, Aurora, et al[ Go to top ]

    I think one of the greatest benefits I've personally seen derived from Spring is the ability to deploy a comparable component-based architecture completely in the web container (not the EJB container) of an application server. Really the power comes from AOP where you can manage a lot of things (i.e. security, transactions) orthogonally to the rest of the application.

    The current company I'm at has had a fair amount of success using Spring to build a commercial offering (called AppsCreate) where we can build and customize applications completely at runtime (no IDE) for our customers.

    I'm actually giving two webinars in the next 2 weeks going over this product, Spring, Agile Development, and Model-Driven Development and would be glad to have some of the lurkers from TSS hop in and blast holes in everything. :)

    mike, logicalapps, www.logicalapps.com

    (webinar registration available at http://www.logicalapps.com/webinar/topics.html)