Discussions

News: An XML-free web framework, Mentawai 1.0, released

  1. Mentawai is a web framework created to simplify web applications development, as always, but this time the proposal is: no XML for configuration at all. Configuration is accomplished programmatically for actions, flows, and validation.

    A quick start shows the use of a controller servlet and an ApplicationManager class, loaded by default from the unnamed package.

    What do you think of this idea? How long do you think it might be before someone writes an ApplicationManager that loads a configuration from XML?

    Other resources:

    Threaded Messages (33)

  2. If I need to choose oldschool MVC framework I'll choose Struts.
    Same lines that you write in xml, the same is in java code.
    "Change awl on Soap"
  3. Типа Шило на Мыло, кто не понял
  4. Its not just about the XML[ Go to top ]

    Its not just about the XML, or lack of it. One nice thing about an XML-driven configuration is that it forces you to externalize the configuration of the component the configuration is for. Often times, thius leads to a set of configuration objects that you *can* use programatically.

    For example, in struts, you can programatically get the configuration data. You can even construct the objects at will. I'm not certain that you *can* modify the struts configuration on the fly, but if you can't right now, the API is pretty darn close to allowing you to (maybe they just haven't targetted that feature).

    As others have pointed out, the strength is that you're not limited to XML. If you can programatically configure, then you can build adapaters that: read from XML, expose through JMX, use a management web page, read a database, etc.

    Too often people look at XML as the end-all of defining configuration data. But as others have said, XML has a lot of advantages durign development time that evaporate in many production environments. If you have progrmatic configuratiof, you can manipulate this at runtime much more easily.

    One caveat, those in the configuration management areas might be irked that the configuration isn't under CM control in those cases, so it may be necessayr to not only be have a programatically modifable configuration, but also one that can be exported/imported for CM purposes.
  5. no XML for configuration[ Go to top ]

    I see programmatic configuration not as a bad thing:

    During development changing a parameter in source is as easy as changing in XML (type and press CTRL-S in Eclise). During runtime changing e.g. an ebj-jar.xml is as hard as changing in code: you have to re-build, re-package, re-test and redo release procedure.

    And a big advantage of parameter in source code: the compiler will be able to check them.

    But the way to go for java parametrisation is to use JMX with the manageable parameters appearing in the application server management guis.
  6. no XML for configuration[ Go to top ]

    There is a fine line between both camps:
    For instance, I am currently working on an application that is completely hold together by Dependency Injection. Whenever there are bigger refactorings it is hell to try to configure everything again, as you don't catch configuration problems until at runtime.
    Eventually I decided "to screw it!" and just write a class where all the injecting is hard-coded. Not beautiful, but it works, and doesn't compile if there is a problem.
    As long as you still code for injection (no dependencies on how objects are created or injected), I can still add Spring to the mix once I feel the applications API is stable enough to warrant it.

    Ok, to get to the point: what I would like to see more is "dual mode" of configuration, so you can "hard-code" configurations programmatically during development, but then switch over to XML-based configuration when getting more stable.
  7. There is a fine line between both camps: For instance, I am currently working on an application that is completely hold together by Dependency Injection. Whenever there are bigger refactorings it is hell to try to configure everything again, as you don't catch configuration problems until at runtime.

    This is an often overlooked aspect of the configuration and DI hype!
    The real question is not XML vs. Non-XML configuration but dynamic configuration vs. static, well, coding.
  8. Eventually I decided "to screw it!" and just write a class where all the injecting is hard-coded. Not beautiful, but it works, and doesn't compile if there is a problem.

    So you're saying the code is "better" because the static checking done by the compiler tells you when there is a problem, when if the configuration is in XML you don't find out until runtime (possibly not until you try to access the configured resource) that there is a problem, and it may not be obvious where the problem is.

    Seems to me the solution should be tools that do static analysis of configuration files based on a specified runtime environment. All the compiler is doing is making sure classnames, method signatures, etc are all valid and in the classpath. There's no reason a tool couldn't read a XML file and do the same thing...or more.
  9. >So you're saying the code is "better" because the static checking done by the compiler tells you when there is a problem, when if the configuration is in XML you don't find out until runtime

    Nope, not saying that code is better at all, I quite like and prefer Dependency Injection via configuration.
    But during development when API's are still going through heavy refactorings from time to time, a "hard coded" approach may save time up until you are at a point where you don't expect much change anymore.
  10. no XML for configuration[ Go to top ]

    Why not create your IConfiguration through a factory and have a StaticConfiguration (providing the default configuration giving you compiler warnings etc) and an XMLConfigureation extending the StaticConfiguration (so an admin can override the defaults) ... this should satisfy both camps (Team "Programmatic configuration" and team "XML configuration") ... I think some dusty corner in my brain thinks "Chain Of Responsibility"
  11. It's interesting that in the Tapestry world, as we steer towards a more programatic approach (i.e., annotations and the like), we're getting push back from people who LIKE the XML ... they like that they can make changes to the XML and see the results immediately, whereas with Java code, it will take a redeploy (to get the new class definitions in place).
  12. Hotswap may help[ Go to top ]

    For example eclipse (not only) in debug mode can dynamically swap newly compiled java code changes at runtime.
  13. It's interesting that in the Tapestry world, as we steer towards a more programatic approach (i.e., annotations and the like), we're getting push back from people who LIKE the XML ... they like that they can make changes to the XML and see the results immediately, whereas with Java code, it will take a redeploy (to get the new class definitions in place).

    I think what you guys are doing with Tapestry is great, but from a toolability and deployment standpoint, there will always be a requirement to support some degree of XML in any framework.
  14. they like that they can make changes to the XML and see the results immediately, whereas with Java code, it will take a redeploy (to get the new class definitions in place).

    I got these replies so many times that I am starting to think I may be wrong on my thoughts.

    1) Can't you just keep the ApplicationManager.java outside your main application (in the root package for example), so you can recompile JUST this class and not the whole thing for redeploy?

    2) Don't you have to restart your application context when you change the XML ?

    If 1 and 2 is correct, so what is the advantage? Save a quick compile ?
  15. not quite[ Go to top ]

    Tapestry and JSF Facelets use aproach
    where xml descriptors read changes at runtime and compiles
    them to some in-memory pooled or singleton representation. This behaviour can be changed in production to remove small overhead of tracking changes. But in development all changes applies immediatly.
    Althought this behaviour not a case when using Default xml bean factory in spring whereas web-application reload must occure to pick up changes. Some advanced bean factory implementation can avoid development overhead of such redeploy(reload)
  16. Someone likes XML configs, someone likes programmatic set-up.
    I see no difference except for syntax. Configuration is done by Copy-Paste in both cases.
  17. Not a big JSP fan[ Go to top ]

    I am so glad wicket and tapestry allow me to write web apps without having to know jsp.
  18. Not a big JSP fan also[ Go to top ]

    I am so glad wicket and tapestry allow me to write web apps without having to know jsp.

    I tought i was the only one in the world who didn't like jsp. Even when you know it it still a relieve not having to use it. Unfortuanally most "architects" still think we should use it , morans.
  19. I am so glad wicket and tapestry allow me to write web apps without having to know jsp.
    I tought i was the only one in the world who didn't like jsp. Even when you know it it still a relieve not having to use it. Unfortuanally most "architects" still think we should use it , morans.

    What do you like instead of JSP ??? Velocity ??? Freemarker ???
  20. I am so glad wicket and tapestry allow me to write web apps without having to know jsp.
    I tought i was the only one in the world who didn't like jsp. Even when you know it it still a relieve not having to use it. Unfortuanally most "architects" still think we should use it , morans.
    What do you like instead of JSP ??? Velocity ??? Freemarker ???

    Just classes and a render machine. Like JSF without JSP. I actually build my one framework a while ago because I couldn't find what I was looking for. JSP and alikes are terrible, I really found out how terrible it is after I dropped it forever. I tend to get emotionally on this subject because for my work I still have to use it and people do such stupid things with JSP whereafter I can straighten things out again. Most days I leave the office in a state of total frustation while I know everything could have been so much easier.
  21. What about those nice and fency web page layouts and designs ??? Should I fire my web designer ???
  22. What about those nice and fency web page layouts and designs ??? Should I fire my web designer ???

    No unless you want your pages to look like crap ;-). Serious why do you think that JSP is the only way to have a bridge between designer and programmers. I must agree that initially JSP and alikes are misleading faster, just do a saveas and programmers can do their thing. Thereafter the shit hits the fan (copy/paste programming , java in markup , shattered javascripts all over the place etc.etc.)

    Since (x)html is hierarchical it can be perfectly translated into a class model. This can be done either by hand (tedious but not to bad) or by tools. The point is that a REAL component approach is then possible wich unleashes the power of OO. JSP and alikes leads us back to the age of assembly. Unfortunally most of us are so brainwashed that they cannot or don't want to see that. For the ones that cannot see it I feel sorry, for the ones who dont want to see it I have hope.
  23. a question[ Go to top ]

    It's not about xml or programatic. I'ts about...
    Do we need another (previously in house) old-fashioned model2 mvc web framework?
  24. another question[ Go to top ]

    It's not about xml or programatic. I'ts about...Do we need another (previously in house) old-fashioned model2 mvc web framework?
    Who is 'we'?
  25. Hmm...[ Go to top ]

    "Casual Visitor" means nothing.
    we means "Java Developers community"
    I can write simple addon to Struts to configure it programmaticaly (as methioned in other posts).
    Question remains...
  26. Well ...[ Go to top ]

    we means "Java Developers community"

    I'm pleased to meet the Java Developers community spokesman.
    I can write simple addon to Struts to configure it programmaticaly (as methioned in other posts).Question remains...
    The question remains whether one should 'configure' at all instead of 'just' programming. KISS!
  27. Someone could easily extends ApplicationManager and/or ActionConfig to do all kinds of configuration approaches. Configuration freedom !
  28. This framework looks very much like Struts, just that it has no XML for configuring actions. I didn't dive into the framework to find if there are other benefits, but the sample HelloWorld app didn't bring out any other advantages. So, I am not sure if having no XML alone would attract a big following.

    On a similar note, I liked the way Ruby on Rails handles actions. The following snapshot is from an article published on TSS a few days ago.

    01 class OrderController < ActionController::Base
    02 def list
    03 @orders = Order.find_all // Find all orders and set instance variable
    04 // framework automatically forwards to list.rhtml
    05 end
    06
    07 def delete
    08 id = @params["id"] // Get the order id from the request
    09 Order.delete(id) // Delete the order
    10 redirect_to :action => "list" // Forward to the list action (list method)
    11 end
    12 end

    This looked "natural" to me with no XML or programmatic action setup.
  29. Why not take away Java and using only XML?

    For example, with OpenXava you can develop a J2EE application only with XML, in a simple and rapid way.
  30. - Convention over Configuration: Everything have defaults so you lose little time doing boring setup. For example: all i18n files have default directories where the framework looks for them.

    - Input/Output approach, instead of a pure action injection approach like WebWork. But I know sometimes the injection approach is better, and this again is a matter of taste, so you can use an InjectionFilter to accomplish the same results. You are in control with ready-to-use, simple and easy filters.

    - Simple tags you can use that save lots of time. You can also use them together with JSTL, EL and Velocity. You can call tabligs from inside a velocity template, too.

    - Inner actions are cool!

    - The main goal of this framework is not to be an one-solution-for-all-problems framework. it strives to be a don't-make-me-think-much framework. It's gotta be simple, really simple, so people can build web applications with joy. IMHO, most of the web frameworks are not simple and straighforward, so once people learn them, they don't want to leave them. The more time you invest to learn something, the more emotionly involved you become. That's why is hard to ask a guy who is working with Struts to try some different stuff.
  31. Please see:

    http://pandonia.canberra.edu.au/java/jini/tutorial/Config.xml

    I say no more!
  32. struts without XML?[ Go to top ]

    I think we can do better than that.
  33. I think XML configuration is a big trouble too, especially in some highly-DI(Dependency Injection)-configurable framework like Spring. But coding could be 100 times more troublesome without IDEs. So I prefer to have a Integrated Configuration Management tool, rather than a XMLess framework
  34. www.aerolineasata.cl[ Go to top ]

    Aerotransportes Araucania - Aerolineas ATA - Empresa dedicada a brindar servicios aéreos Taxi Aereo, Vuelos regulares a Isla Robinson Crusoe (Arch. Juan Fernandez), Ambulancia Aerea, Fotografía Aerea, Fotogrametría, Filmaciones infrarrojas, Patrullaje Forestal y Costero, Publicidad Aerea, Carga Aerea, Vuelos de Turismo, Escuela de Vuelo y Mantenimiento - www.aerolineasata.cl