Home

News: RSF ("Reasonable Server Faces") version 0.6.1 released

  1. RSF ("Reasonable Server Faces") is a Java open source web programming framework based on Spring, with roughly the same scope as Sun's JSF. Unlike many other frameworks which simply offer "integration" with Spring, RSF is built entirely from a set of overriding Spring contexts, offering configurability to users.

    The presentation layer of RSF is based on a fast and minimal pure-HTML templating engine, IKAT. RSF might therefore be of interest to users of Wicket, for example, who are irritated with Wicket's heavy-component architecture and lack of respect for IoC idioms. Similarly, JSF users will perhaps be happy to leave behind the constant obstruction of the "behaviour-rich" JSF component layer and battle for control of Javascript and layout in the view layer.

    RSF aims for zero-server-state request processing, avoiding reliance on session storage wherever possible, while maintining a clear separation between render and action cycles, making it ideal for use in portal-style development.

    Building on its foundations of Spring proper, RSF takes Spring yet further with RSAC, a lightweight Spring clone that it uses to operate its request container. This produces benefits in the area of ORM (first-class "transparent" Hibernate support has been in since 0.6) as well as request processing flexibility.

    Despite all these capabilities, RSF is quite small, weighing in at an ultra-slim 11k LOC. RSF attempts to continue the Spring tradition by intruding on your application code to the tiniest possible extent.

    New in RSF 0.6.1 are a greatly improved build procedure, numerous rendering and performance fixes and a smattering of new components.

    There are also support forums available.

    Threaded Messages (53)

  2. What if I don't want/need to use Spring? Can I use RSF without Spring at all?
  3. lack of respect?[ Go to top ]

    Wicket has 'lack of respect of IoC idioms'? Very funny, as Wicket is an unmanaged framework, meaning that framework clients are in charge of creating component instances and hierarchies. It's amazing how that is considered 'heavy' and 'disrespectful of IoC' as Wicket seems to be one of the few - or maybe the only - framework(s) that tries to get back to the basics: plain Java and plain HTML!

    Furthermore, if Spring is important to you, you can just use one of the integration packages. For instance, this how you could inject Spring dependencies in ANY component you like using annotations:
    @SpringBean private ContactDao dao;

    or
    @SpringBean(name = "someName") private ContactDao dao;

    Pretty convenient and non-obtrusive, no?

    For various reasons we choose to set private fields directly; there has been some discussion about that, but it's a couple-of-hours job to implement any custom strategy you want, just as there is an alternative strategy that is based on commons-attributes instead of annotations.

    Btw, another not-too-loudly advertised feature of Wicket is that it supports stateless pages. If you really feel the need to avoid storing some of your pages in the session; that can be done without sacrificing too much of the programming model.
  4. RSF, Spring and Wicket[ Go to top ]

    In answer to these questions, no, you can't use RSF without Spring, although since RSF doesn't pass on any of these dependencies you need not see them in your own code.

    But if you simply don't "get" IoC as both of these posters don't seem to, then RSF is not for you. Personally I find annotations used in the way you describe messy and intrusive and do not address the underlying problem of having the injection proceeding the *wrong way*. You are injecting the DAO into the bean, rather than the bean into the handler, thus polluting your business model with persistence semantics.

    I didn't mean to particularly "bash" Wicket in my introduction, but since I felt it was in many ways the "best" and most closely related other framework that I had to highlight the differences in approach. Wicket in general intrudes on its clients with framework base classes and interfaces which I feel is an unacceptable burden.

    I think RSF gets back to "plain Java and plain HTML" also, but we will have to agree to differ as to the strategy. I think the Spring philosophy for this is the correct one, and hope to take it further.
  5. RSF, Spring and Wicket[ Go to top ]

    But if you simply don't "get" IoC as both of these posters don't seem to, then RSF is not for you.
    Yes, I "get" Ioc. What I don't "get" is the heavy dependency on Spring, since there are other IoC frameworks out there, and they are supposed to lower code coupling intead of create more dependencies. Imagine if I already had a system which uses HimeMind, if I wanted to use RSF I'd be stuck with 2 IoC on the same project. Heavy dependency on a specific framework can be considered an intrusion too.
  6. Spring dependence[ Go to top ]

    OK - the point is that any "competent" IoC framework should be equivalent to any other one. Once the dependence has been removed, it should be immaterial to the client code by which means it has been removed. I chose Spring largely since it is popular and has good tool support, even though I'm somewhat unhappy about how big the non-core parts of it have got.

    The main win for RSF in terms of Spring as I see it is i) developer familiarity and ii) the increasingly excellent tool chain - for example you can now validate RSF request context using the same Spring IDE Eclipse plugin that works for anything else.

    Yes, I take the point that during these transition times there will be just the same battle amongst IoC frameworks as there was previously amongst "heavy" ones, but thankfully this is a battle that the client code can be left out of. But I hope you'll agree it's clearly better for RSF to be fundamentally based on some (and hopefully recognisable) form of IoC rather than none at all.

    As I mentioned, the fact that RSF is closely bound to Spring need not be visible to clients, except insofar as they will need to use Spring-formatted configuration.

    Apologies for inferring you didn't "get" IoC, in my experience that had usually been the most common reason I had heard for people saying "do I have to use Spring?"
  7. Spring dependence[ Go to top ]

    Apologies for inferring you didn't "get" IoC, in my experience that had usually been the most common reason I had heard for people saying "do I have to use Spring?"

    And then there are people that think IoC can be just another tool in you shed. They say: 'use it when appropriate, or something else when that makes more sense'. Poor, ignorant people.
  8. Spring dependence[ Go to top ]

    Well, no need for sarcasm here. I just evidently think that it makes sense in more cases than you and the other Wicket developers do :P

    But yes, I do think that the widespread adoption of Spring (and analogous "true" IoC containers such as Pico &c) is the single most productive result in development in the last 10 years. There's room enough for people who disagree of course.
  9. RSF, Spring and Wicket[ Go to top ]

    But if you simply don't "get" IoC as both of these posters don't seem to, then RSF is not for you.
    Yes, I "get" Ioc. What I don't "get" is the heavy dependency on Spring, since there are other IoC frameworks out there, and they are supposed to lower code coupling intead of create more dependencies. Imagine if I already had a system which uses HimeMind, if I wanted to use RSF I'd be stuck with 2 IoC on the same project. Heavy dependency on a specific framework can be considered an intrusion too.

    You mean like Tapestry's 4's heavy dependency on Hivemind?
  10. RSF, Spring and Wicket[ Go to top ]

    But if you simply don't "get" IoC as both of these posters don't seem to

    Come on.. what is there to get about IoC?! UI components are the top layer of your applications. Why on earth does that need to be 'non-invasive'? I see no need to defer dependencies in the view layer. What would be the use? You want to create your widget hierarchies from spring configuration? Yech.
    Personally I find annotations used in the way you describe messy and intrusive and do not address the underlying problem of having the injection proceeding the *wrong way*. You are injecting the DAO into the bean, rather than the bean into the handler, thus polluting your business model with persistence semantics.

    Huh? Business model? Handler? Hellow, we're talking about user interface components here.
    I didn't mean to particularly "bash" Wicket in my introduction

    No problem, free publicity is always welcome. Unfortunately I feel obliged to step into another discussion.
    Wicket in general intrudes on its clients with framework base classes and interfaces which I feel is an unacceptable burden.

    I guess the next thing people invent is pluggable collection classes so you 'wire' different implementations for that instead of directly depending on java.util.List and friends. Or some framework that let you do Swing or SWT widget construction from an xml file. I have no doubt there is a market for that.
    I think RSF gets back to "plain Java and plain HTML" also, but we will have to agree to differ as to the strategy. I think the Spring philosophy for this is the correct one, and hope to take it further.

    Well, whatever you like. I took a quick look at the examples, and I couldn't see much Java code between the lines of xml. But I'm sure any Java code users of your framework have to write is non-intrusive.
  11. RSF, Spring and Wicket[ Go to top ]

    Come on.. what is there to get about IoC?! UI components are the top layer of your applications. Why on earth does that need to be 'non-invasive'? I see no need to defer dependencies in the view layer. What would be the use? You want to create your widget hierarchies from spring configuration? Yech.
    Huh? Business model? Handler? Hellow, we're talking about user interface components here.

    Yes, I think where we're talking somewhat at cross purposes is that these "user interface components" you're talking about are things I feel simply shouldn't exist. If you look at the RSF "component" set you will see that it is virtually nonexistent, certainly in terms of behaviour. The point is that a "user interface component" will always be one provided by the framework rather than the developer and hence will be an extremely undesirable dependency to him/her.

    I do position RSF as the "framework for people who hate frameworks" - it's job is to be as small as possible and to get out of the way just as quickly as possible. Most authors of frameworks don't seem to grasp that none of their users actually want to use their code.
    Well, whatever you like. I took a quick look at the examples, and I couldn't see much Java code between the lines of xml. But I'm sure any Java code users of your framework have to write is non-intrusive.

    To answer the specific point here and above about how view hierarchies are created, you probably haven't had the time to familiarise yourself with the way RSF Views are produced - as an alternative to XML definition you may also choose to write these in pure Java, which is actually the recommended style. Naturally this Java code will have to have framework dependence, and no, the individual "widgets" as you call them are not Spring-configured, only the objects that produce them and their binding targets are.

    But in contrast to Wicket "widgets" RSF components represent a minimal burden because they represent pure data. View production is just a long sequence of "new" calls, but creating a much more "flat" structure - all actual behaviour lives in clean dependence-free developer code.
    No problem, free publicity is always welcome. Unfortunately I feel obliged to step into another discussion.
    You're quite welcome :P Whatever happens from this represents a clear win against the morass of JSF/Tapestry/Webwork/Struts currently dominating the industry.
  12. RSF, Spring and Wicket[ Go to top ]

    If you look at the RSF "component" set you will see that it is virtually nonexistent, certainly in terms of behaviour. The point is that a "user interface component" will always be one provided by the framework rather than the developer and hence will be an extremely undesirable dependency to him/her.

    I strongly disagree with that. There was a recent other thread where people stated having custom components should be rare. I think that's wrong for many reasons, but maybe the most important one - from my perspective - I view components like I do objects in general: as means to express concepts. Just like the real world has dogs, houses and cars, user interfaces have buttons, forms, links, but also like there are golden labradors, there are address forms and search/ results panels. I believe it is useful to be able to look at user interfaces like that, and subsequently to have programming constructs for the same matter. And just like objects, I like components to have state and behaviour when that is relevant. See, that's really all Wicket tries to do: stay as close to what Java originally is as possible, while also staying as close as possible to the purpose of using a web framework in the first place: dynamic markup (HTML).
  13. RSF, Spring and Wicket[ Go to top ]

    I strongly disagree with that. There was a recent other thread where people stated having custom components should be rare. I think that's wrong for many reasons, but maybe the most important one - from my perspective - I view components like I do objects in general: as means to express concepts. Just like the real world has dogs, houses and cars, user interfaces have buttons, forms, links, but also like there are golden labradors, there are address forms and search/ results panels. I believe it is useful to be able to look at user interfaces like that, and subsequently to have programming constructs for the same matter. And just like objects, I like components to have state and behaviour when that is relevant. See, that's really all Wicket tries to do: stay as close to what Java originally is as possible, while also staying as close as possible to the purpose of using a web framework in the first place: dynamic markup (HTML).

    Yes - this is definitely where we part company. In my view this view of "object-orientation" is slightly old fashioned, and I'm indeed keen *not* to stay as close to "Java originally" in this regard. In my view, in terms of later thinking (beginning with John Lakos &c), "dependence is everything, and objects are nothing". Or while not exactly nothing, should be seen firmly in the light of their impact on dependence, and not the reverse.

    That said, RSF doesn't stop you producing programming constructs which correpond to larger abstractions in the UI, the point is that what constructs you produce are *no longer constrained* to be part of a hierarchy defined by the framework. See my post above for alternative usage styles that I imagine will be built on the foundation of RSF components.

    In terms of getting away from the "90s-style" O-O I am very much set on emphasising the aggregation (of structures) and polymorphism (through interfaces) rather than inheritance (through extension) which seen in terms of its dependency impact is unquestionably bad.

    Where we're 100% in agreement however is on the importance of HTML, dynamic or otherwise. It's one of the core realities of the world that simply isn't going to go away, and where both Wicket and RSF win hands down is freeing the design experts to just put down the page definitions they need to satisfy their users, without worrying about what some blasted "web framework" is going to tie their hands with.
  14. RSF, Spring and Wicket[ Go to top ]

    "dependence is everything, and objects are nothing". Or while not exactly nothing, should be seen firmly in the light of their impact on dependence, and not the reverse.

    And
    O-O I am very much set on emphasising the aggregation (of structures) and polymorphism (through interfaces) rather than inheritance (through extension) which seen in terms of its dependency impact is unquestionably bad.

    While that does make way for a good bunch of theoretical discussions - please don't get me started on interface vs abstract class zealotism -, I fail to see why this is relevant for the UI layer. Unless you have a special need to not bind to a specific framework - why avoid it at all cost? What are the real life problems you are fixing with that?

    Another thing I fail to see is that striving for object orientation in terms of encapsulation conflicts with thinking about object dependencies. That is a natural part of object orientation isn't it? IoC is not a foreign concept to OO and like I said I think it's just another tool in the shed.

    With staying 'close to Java' I mean that I'd like to leverage the language instead of fighting it, and try to minimalize the introduction of foreign concepts.
  15. RSF, Spring and Wicket[ Go to top ]

    While that does make way for a good bunch of theoretical discussions - please don't get me started on interface vs abstract class zealotism -, I fail to see why this is relevant for the UI layer. Unless you have a special need to not bind to a specific framework - why avoid it at all cost? What are the real life problems you are fixing with that?
    The real life problem is that of making apps more portable and minimising the amount of time a developer spends dealing with framework-specific code, in aggregate. This admits that no framework is perfect (although I know lots of authors who think that their frameworks are) and will all someday be destroyed and replaced. Making frameworks as slim and unobtrusive as possible is only basic courtesy to your users.

    Anything special about the UI layer of an app? Traditionally I find it's invariably the worst one and everyone would appreciate it if it was as little tangled as it could be. Surely it could benefit *more* from dependency management than any other part.
    Another thing I fail to see is that striving for object orientation in terms of encapsulation conflicts with thinking about object dependencies. That is a natural part of object orientation isn't it? IoC is not a foreign concept to OO and like I said I think it's just another tool in the shed.

    With staying 'close to Java' I mean that I'd like to leverage the language instead of fighting it, and try to minimalize the introduction of foreign concepts.
    IoC is not so much "foreign" to O-O as perpendicular. Seen in terms of IoC some parts of O-O as traditionally formulated can be seen as "good" and others as "bad". Actually I never really liked the term "IoC" anyway since it somehow implied that your control was ever the wrong way round in the first place... it would be better to call it something like "dependency management" but what can you do.

    Again with your last point we part company - rather than "fighting" Java I'm certainly extremely keen to just selectively disuse some (possibly quite large) parts of it, and am happy to introduce as many foreign concepts as necessary if they make peoples' life easier.
  16. RSF, Spring and Wicket[ Go to top ]

    .Again with your last point we part company - rather than "fighting" Java I'm certainly extremely keen to just selectively disuse some (possibly quite large) parts of it, and am happy to introduce as many foreign concepts as necessary if they make peoples' life easier.

    Well, for your and your user's sake, I hope you succeed in that.
  17. RSF, Spring and Wicket[ Go to top ]

    Another question, then: where in RSF should "view logic" code reside? For example, if I want a component to change its background color depending on another component's value, where should this code reside in RSF?

    Also, if I want to extend an existing component and just add this behaviour to it, how could it be achieved in RSF?
  18. RSF and view logic[ Go to top ]

    Another question, then: where in RSF should "view logic" code reside? For example, if I want a component to change its background color depending on another component's value, where should this code reside in RSF? Also, if I want to extend an existing component and just add this behaviour to it, how could it be achieved in RSF?

    "view logic" is held in the ViewProducers, which are designated to be the place such stuff goes by having visible framework dependence. These are simply Java (Spring) beans implementing a one-line interface. One point I should make re. "depending on another component's value" is that RSF "components" do *not* depend on other components, they depend only on the model. Once they have been constructed they disappear into the renderer and are forgotten forever (*at least potentially*).

    RSF components only exist to reflect HTML/view tech "realities" and it's not envisaged that users will extend them lightly if at all. But this is not to say that there is no room in RSF for a kind of higher-level "component" that has the behaviour you describe, which is simply the behaviour of producing (a) different RSF component(s) depending on model conditions. But the good thing about these kinds of "components" is that they live in developer-land and can be developed and strung together using whatever methodology you like, whether it's Jython, HiveMind or some other wacky scheme.

    In terms of "extending" please refer to my other comment on object-orientation in the message below.

    RSF components have been created as a crucial "factorisation" point for the view technology in use (HTML, WAP, XUL) or whatever, and are exactly as thick as they need to be to make this factorisation proper. This was the original promise of JSF, which got grievously warped when Sun decided as usual that they could model *all* useful component behaviour within their framework.

    I envisage lots of different application styles (AJAX-style persistent components &c) will be supported on top of the RSF components as a minimal foundation - but the point is the framework as it stands even allows you to build *nothing* on top of them, which will be the choice for users who want the highest performance and lowest server overhead.
  19. RSF, Spring and Wicket[ Go to top ]

    I think RSF gets back to "plain Java and plain HTML" also

    I am a big fan of Spring. And I have been a big fan of Tapestry for a long time - until I started using Wicket. The reason I fell in love with Wicket is because it is the /ultimate/ in plain Java.

    Like in Tapestry, RSF components are limited to being beans, and the fact that they are managed further eliminates some programming constructs that you could use on pojos.

    There is something very intuitive about configuring your components through their constructor (good citizen pattern makes sure you didnt forget to call some setter, not to mention your ide lists all the constructors for you) and implementing an abstract method to add your event handler:

    new Button("delete", "Delete User") {
       onSubmit() {
           userService.delete(.....);
       }
    }

    Yes, this makes injection of ioc dependencies harder because they need to be injected before the component's constructor has started since they will most likely be used there. As Eelco pointed out we have an elegant solution for that. As a big fan of Spring I can say that wicket's integration with spring is great.
  20. RSF, Spring and Wicket[ Go to top ]

    new Button("delete", "Delete User") {
       onSubmit() {
           userService.delete(.....);
       }
    }

    Yes, in terms of of plain Java this makes a lot of sense, but in terms of webapps, less so. In particular you now have a representation of your Button that makes no sense except as a collection of Java objects (complete with inner class).

    The implication of this is that the subsequent request cannot be handled without this object tree having been stored somewhere - either it consumes server resources, or is somehow stuffed into a client field as a serialized Java object representation - yuk.

    Either way, the user is *forced* to bear some cost which may to him be unacceptable. Nothing stops you building heavy components on top of RSF, but at base an RSF HTML form is just that - a simple collection of values and bindings from which the submission can be interpreted in isolation. IMO this is the base level of "natural" treatment of HTML and HTTP that a framework should build from.

    I've already made my views on the "elegant solution" for injecting Spring-managed services into framework beans clear - while this idiom has come to be supported by Spring I think it is a step decisively away from the original goals of Spring and other IoC containers, which was to help developers manage their dependencies to be both clear and expressed in the correct direction.
  21. RSF, Spring and Wicket[ Go to top ]

    The implication of this is that the subsequent request cannot be handled without this object tree having been stored somewhere - either it consumes server resources, or is somehow stuffed into a client field as a serialized Java object representation - yuk. Either way, the user is *forced* to bear some cost which may to him be unacceptable.

    Ah, there we go. So it's about optimization. For a second I thought we were talking conceptual stuff here.
  22. RSF, Spring and Wicket[ Go to top ]

    It's about optimisation *and* concepts. This "storage of the server state" is a procedure that the developer needs to go through, which has costs both in time and headache. The headache, in this case, is ensuring that all the material you want stored is properly serializable in whichever receptacle you want to put it, whether it is in a URL, a client form, a session or a database table or indeed anything else decided on the drop of a hat by the deployer/administrator of your app. Now say your Wicket user decides that what they want in their state is a reference to a Hibernate entity - in half of these cases you would be SOL - but which half?

    Wicket makes this problem hard, by allowing arbitrary stuff in server state. RSF makes this easy by designing its minimum state such that it i) as small as possible, and ii) could be stored absolutely anywhere.

    Costs can be measured in all sorts of units. Time, space, dependency, developer effort, and just general nastiness.
  23. RSF, Spring and Wicket[ Go to top ]

    Costs can be measured in all sorts of units. Time, space, dependency, developer effort, and just general nastiness.

    Now here is something we agree on :) Though obviously not on how that would be filled in. And I suspect we would need to bring our boxing gloves when we would get to the 'general nastiness' part.
  24. RSF, Spring and Wicket[ Go to top ]

    In particular you now have a representation of your Button that makes no sense except as a collection of Java objects (complete with inner class)

    Why doesn't that make sense? A button is a thing I can see on a user interface, and in this case it can receive it's own events and possibly hold it's own state (though not a common thing for buttons to have). You would use button components if you want to differentiate between several buttons. E.g. when you have a cancel, a next and a previous button. If you wouldn't need that, e.g. you just have one submit button, you don't need to use a wicket component at all, but just use the HTML tags.

    Furthermore, what's wrong with the concept of a button? It might have (packaged?) styles attached to it, might use a special model to display some internationalized label and it might have behaviour such as being turned on or off depending on some state.
  25. Button component[ Go to top ]

    new Button("delete", "Delete User") {
       onSubmit() {
           userService.delete(.....);
       }
    }

    Out of interest, the RSF equivalent to this looks like:

    UICommand mybutton = UICommand.make(parent, "delete", "Delete User", "#{userService.delete}");

    The similarities are as interesting as the differences - firstly you couldn't say this was not "pure Java", and it is clearly at pretty much the same level of abstraction. The root difference is that the resulting structure isn't a "Java object" in quite the sense of a Wicket component since i) it is not actually going to do anything (no "onSubmit" method), and ii) it is not going to stick around.

    The knock-on differences are i) that as a result of not being a "fully hydrated" Java object, there is a lot more flexibility as regards past history, and future fate. This is important in the heterogeneous world we live in, and webapps more than anything show this up. In particular it would have been very easy to make this "object" using, say, XML, or some other crazy app-generation strategy (and there are a lot of them about). At the other end, similarly, it is very much easier to recognise its embodiment on the client-side if you are trying to poke at its encoded form with some Javascript.

    So, the key to making this work is the "bindings" system, which while based on the ideas from JSF, is a good deal more flexible. The problem as you note with your "(.....)" is how on earth the userService is to be told which user to delete. In Wicket you can solve this problem relatively easily in some cases by perhaps having the argument visible in the "closure" environment of the inner class - or simply arranged to have it assigned into the button at some later point. Although things like Hibernate would tend to complicate this simple picture in quite a nasty way.

    In RSF, this is solved by firstly having the "userService" binding i) refer to a request-scope entity rather than a statless one, and ii) arranging to have the correct entity reference injected into it on the next request cycle by means of an EL binding.

    This might, for example, look like this:

    mybutton.parameters.add(new UIELBinding("#{userService.target}", new ELReference("#{user.38aa9304}"));

    (where, say, 38aa9304 happened to be some ORM-derived "ID" for the user)

    So, it's important to take stock of what we've gained and lost - as you note, this isn't quite "Java" the way our grandfathers wrote it - we've lost some of the "safety" and idiomaticity that a pure-Java object world gives us. But what we have gained is i) great savings in "costs" in various categories. For example state - this button consumes no resources anywhere except in the client while it is alive, and in transit can be put virtually anywhere. ii) much better decoupling between our data model and the view layer - in particular we don't care how the binding user.38aa9304 works, and we don't need to worry about establishing a correspondence between what it refers to at the time of constructing the button and at the time of handingly the request. Of course Hibernate and things like it conspire to make this issue particularly explosive.

    In fact RSF has a special kind of binding that saves even more typing - you don't even need to write the userService for cases like this, since you can use a "deletion binding" (default implementation is provided as an example for a Hibernate-derived model)

    UICommand mybutton = UICommand.make(parent, "delete", "Delete User", null);
    mybutton.parameters.add(new UIDeletionBinding("#{user.38aa9304}"));

    I think it's hard to come up with a solution that involves less typing than this, added up here and throughout the codebase.

    In terms of your other requirements (styles, i18n, off/on-ness) all this would be IoC configured in the ViewProducer responsible for issuing the "make" statement above. This would be superior when seen in dependence terms because the coupling of this code to the framework (or indeed anything) is much lighter - whereas in the Wicket case it is coupled to all the code inside Component, FormComponent, WebMarkupContainer et al, (5500 lines!!! Half the code size of all RSF!) in RSF it is coupled only to the name of the ViewProducer interface which it implements, and the code-free classes leading from UICommand up to UIComponent.

    You may well respond that this seems crazy and "anti-Java" in some way, but I can only think it represents a great result and refer you back to Lakos and other proponents of rational dependency management, who have written up the rationale for this kind of design more clearly than I can.
  26. RSF, Spring and Wicket[ Go to top ]

    I think it is a step decisively away from the original goals of Spring and other IoC containers, which was to help developers manage their dependencies to be both clear and expressed in the correct direction.

    I think you are taking this way too far. You will not be swapping your button type from deployment to deployment, so what is the point of having it declared in an ioc container? What is the point of forcing your entire web-ui to participate in ioc when 90% of time these things do not need to be configured and thus have hardcoded dependencies. For the other 10% declare a factory interface and drop an implementation of that into the ioc container.

    Also wrt to heavy objects, one of the things that turned me off from tapestry was the fact that your component hierarchy is very static. The same goes for RSF. In wicket you can swap any component with any other at any point in your application. This adds a huge degree of flexibility when building complex UIs.
  27. RSF, Spring and Wicket[ Go to top ]

    I think you are taking this way too far. You will not be swapping your button type from deployment to deployment, so what is the point of having it declared in an ioc container? What is the point of forcing your entire web-ui to participate in ioc when 90% of time these things do not need to be configured and thus have hardcoded dependencies. For the other 10% declare a factory interface and drop an implementation of that into the ioc container.

    Also wrt to heavy objects, one of the things that turned me off from tapestry was the fact that your component hierarchy is very static. The same goes for RSF. In wicket you can swap any component with any other at any point in your application. This adds a huge degree of flexibility when building complex UIs.

    See above - i) there is nothing costly and "nasty" about participating in IoC, and it is appropriate for a good deal more code than you are arguing. In fact IMO it is appropriate for all objects that have behaviour. ii) The entire webUI does not participate in IoC as I mentioned, since the base level consists of concrete objects that are simply constructed with "new()". iii) the "huge degree of flexibility" you are looking for *is* still there with RSF, only it is now decoupled from the component hierarchy. This flexibility appears at the level of organising ViewProducers which may have arbitrarily structured relations amongst themselves. In terms of my earlier remarks on O-O, this is flexibility through aggregation which is much superior to flexibility through derivation.
  28. RSF, Spring and Wicket[ Go to top ]

    Obviously I dont know exactly how the internals work, so correct me if this is off track.

    In my perspective in a component oriented framework a component is a slice of the entire request life cycle - that is it participates in all the phases - get request attributes, process them, produce output.

    Seems to me the ViewProducer decouples the output away from the components - which is imho a bad design because it breaks component encapsulation.
  29. RSF, Spring and Wicket[ Go to top ]

    this is flexibility through aggregation which is much superior to flexibility through derivation.

    Of course oo isn't just about aggregation, and Wicket isn't either. We made the deliberate choice for derivation for component classes, as we can guarantee a lot of behavior that way and as abstract classes gives more opportunities for hiding implementation details than interfaces do.

    But other than those widget classes, there are behaviors (we use that e.g. for ajax, but also for things like doing header contributions), validators and converters etc, and there are models - first class citizens with Wicket - and resources, and there's the component structure itself. All that is flexibility through aggregation.
  30. RSF, Spring and Wicket[ Go to top ]

    Of course oo isn't just about aggregation, and Wicket isn't either. We made the deliberate choice for derivation for component classes, as we can guarantee a lot of behavior that way and as abstract classes gives more opportunities for hiding implementation details than interfaces do.

    Here I have to strongly disagree. In particular your last statement is completely false - an abstract class by definition could not hide more details than an interface.

    I like sometimes to think that RSF bears the same relationship to JSF as SWT does to Swing. The SWT concept of a component is quite similar in terms of being a pretty "final" thing that exists only to abstract a particular native reality. In particular extension through derivation is strongly discouraged - although note that in RSF unlike SWT I don't actually forbid it through declaring final methods. Although since RSF components don't actually *have* any methods this perhaps isn't through lack of desire :P

    In terms of dependencies, dependency on an abstract base class (especially one with state) is absolutely the worst kind of dependency to express, and should be replaced with an interface/aggregation strategy where it is even slightly possible. I can gladly refer all readers of this thread to John Lakos' marvellous book "Large Scale C++ Software Design".
    But other than those widget classes, there are behaviors (we use that e.g. for ajax, but also for things like doing header contributions), validators and converters etc, and there are models - first class citizens with Wicket - and resources, and there's the component structure itself. All that is flexibility through aggregation.
    Quite so. It's not for nothing that I said that Wicket was probably the best "other" framework out there. From what I saw of your design it was generally well-motivated in many areas, and the templating system is extremely good. The problems re. treatment of state, components and dependencies are fairly fundamental though.
  31. RSF, Spring and Wicket[ Go to top ]

    Of course oo isn't just about aggregation, and Wicket isn't either. We made the deliberate choice for derivation for component classes, as we can guarantee a lot of behavior that way and as abstract classes gives more opportunities for hiding implementation details than interfaces do.
    Here I have to strongly disagree. In particular your last statement is completely false - an abstract class by definition could not hide more details than an interface.

    With interfaces, all methods are public, and interfaces don't carry state and don't have guaranteed internal behavior.

    Anyway, that discussion really got old. If anyone is interested in the discussion on abstract classes vs interfaces for component in Wicket, there are some threads about that in the mail archives. The world hasn't changed since then; it's still grey.
  32. Costs of derivation[ Go to top ]

    With interfaces, all methods are public, and interfaces don't carry state and don't have guaranteed internal behavior.

    From the dependency point of view, "not carrying state" is a golden benefit. Something that doesn't have state that you could have influenced is one more thing you could have failed to screw up. What better way to provide something with "guaranteed internal behaviour" than to provide something whose internal state cannot be corrupted.
    Anyway, that discussion really got old. If anyone is interested in the discussion on abstract classes vs interfaces for component in Wicket, there are some threads about that in the mail archives. The world hasn't changed since then; it's still grey.

    You're right (as you mentioned earlier) that this debate can be seen in many ways as "religious" although I do feel that at the end there are important practical issues involved. Either way, this probably isn't the right place to have it and it is not going to be settled in any reasonable period of time.

    Sometimes the costs/benefits of derivation make sense but I think these times are a lot rarer than people in general appreciate. This is because the costs are generally largely deferred until some far-off time when someone else is maintaining and/or reading your code. If you're extremely forgetful like me, you tend to pay these costs earlier than most people :P

    The larger and more complex a system becomes, the more these kinds of costs tend to predominate, and even slight failures
    of insulation like this can come to make the difference between a system (in which your own code is just one of many competing elements) being comprehensible and its being incomprehensible. Wicket is clearly *extremely* far off from being as screwed up as JSF in this regard with its UIComponentBase of 2,100 lines, many of them stateful. But given you never know where your code is going to end up, especially as a framework author, I think it really pays to be cautious in the long run.

    Cheers.
  33. RSF, Spring and Wicket[ Go to top ]

    Of course oo isn't just about aggregation, and Wicket isn't either. We made the deliberate choice for derivation for component classes, as we can guarantee a lot of behavior that way and as abstract classes gives more opportunities for hiding implementation details than interfaces do.
    Here I have to strongly disagree. In particular your last statement is completely false - an abstract class by definition could not hide more details than an interface.

    Rofl, are you serious? Dont tell me you have never seen a protected abstract method.
  34. RSF, Spring and Wicket[ Go to top ]

    i) there is nothing costly and "nasty" about participating in IoC, and it is appropriate for a good deal more code than you are arguing.
    Well, AFAIK there are some costs:
    1) performance - in RSF's site it is even mentioned that parts of Spring had to be replaced in order to fit RFS's usage, due to performance.

    2) inflexibility - what if one wants to substitute a UI component for another during runtime, using app logic?

    3) complexity - the moment you start putting every dependency into a IoC management, config files can become huge and hard to maintain.
  35. Costs of IoC[ Go to top ]

    Well, AFAIK there are some costs:
    1) performance - in RSF's site it is even mentioned that parts of Spring had to be replaced in order to fit RFS's usage, due to performance.
    In fact I didn't so much "replace" it as build a parallel implementation - AFAIK noone had ever tried to use IoC in the request scope before and the Spring architecture just wasn't up to it. Probably one of the lighter-weight containers like Pico might have proved better, but i) perhaps not, and ii) Pico objectionably uses constructor-type (type-3) IoC.

    To be completely clear, RSF does *not* replace any components of Spring, it makes a perfectly normal use of it in those cases where it is appropriate (application-scope configuration).

    To be sure, until anyone *had* tried using request-scope IoC, the per-request performance cost of using Spring was exactly ZERO since as you know it steps completely out of the way at runtime. So there are no performance costs to IoC per se. However as many Spring users have discovered, the collateral cost of "stepping out of the way" is to deprive users of the benefits of IoC at runtime, hence the plague of anemia problems that are constantly being complained about. If you read the performance section on RSAC, you will see that the runtime cost of a request-scope bean construction is about 5ish microseconds which is not too bad - and with the RSACBridgeProxy this can be brought right back down to zero (or more accurately one reflective function call) for very many kinds of bean. It's arguable that RSF users may not require to wire any request-scope dependencies at all, they seem primarily valuable in internal configuration of the framework.
    2) inflexibility - what if one wants to substitute a UI component for another during runtime, using app logic?
    This is no kind of problem - your app logic sits behind interfaces which can make arbitrary decisions about which type of component to produce on each cycle.
    3) complexity - the moment you start putting every dependency into a IoC management, config files can become huge and hard to maintain.
    At this stage of IoC development this is somewhat true, but only because the tool chain is not fully geared up yet. If you have used SpringIDE for example you will have seen how these files become practically as manageable as your code, and it is getting better and better all the time (SpringIDE 1.3 was released last week). I am dealing with several hundred beans defined in several context files, and I can tell you I'd sure as hell rather deal with THEM than with the equivalent spaghetti code that would be needed to manage them. Bean refactoring support is coming soon.

    SpringIDE at least as much as as Spring's widespread adoption was one of the core reasons behind selecting Spring for RSF's IoC.
  36. lack of respect?[ Go to top ]

    Wicket has 'lack of respect of IoC idioms'? Very funny, as Wicket is an unmanaged framework, meaning that framework clients are in charge of creating component instances and hierarchies. It's amazing how that is considered 'heavy' and 'disrespectful of IoC' as Wicket seems to be one of the few - or maybe the only - framework(s) that tries to get back to the basics: plain Java and plain HTML!

    Well, Aranea subscribes to almost the same principle -- we also use pure Java objects, though we suggest a higher-level abstraction for building GUI than HTML.
  37. Aranea[ Go to top ]

    The Aranea docs looks quite interesting, although I see more discussion in the White Paper about your different controller models than are actually in the documentation proper? Would be useful to see some more examples of the assembly patterns you describe in section 4. In general I found the coding and documentation standards very high.

    Notes - i) AJAX actually doesn't exclude use of the back button in browsers, there are a growing collection of "history libraries" that are looking quite interesting
    (e.g. http://codinginparadise.org/weblog/2005/09/ajax-history-libraries.html)

    ii) you may want to look at RIFE continuations for your continuations support rather than Javaflow since it is somewhat more mature and has been incorporated into at least one other framework (WebWork). Certainly the documentation is somewhat better :P I'm considering RIFE/C for RSF as well...

    I think the sociological points made in the WP introduction are interesting - indeed there will have to be more cooperation and harmonisation amongst different frameworks as time goes on, lest the current continuing anarchy continue to waste peoples effort.

    Given RSF will probably someday be given a superstructure of a "heavy" model, I would say Aranea-over-RSF looks like a better fit than Wicket-over-RSF if only because i) you have more formality as regards how components cooperate, and ii) have given rendering comparatively little attention and are happy to palm the job off to someone else (currently a bunch of JSP taglibs). Aranea-over-IKAT might well not only be quite achievable but even productive since if there's one thing you do need it's a better rendering model (than JSP).

    At this end in the meantime it will be interesting to try to see how far RSF can be pushed without involving *any* kind of heavy-components at all for a while, since I think there's a good chance that sufficient abstractions might develop to actually make them entirely unnecessary for a wide class of apps. GUI development has got into such a rut I feel that people increasingly are unable to think in terms of solutions that don't involve them. I mean, how happy would you be never to have to see anything like this in your code again:

    public abstract class BaseWidget extends BaseService implements Widget {

    BTW, Aranea with only 4K/40K LOC coupled to javax.servlet breaks the record set by Wicket as the least servlet-coupled framework I investigated. Now only 10x as much coupled code as RSF :P (I left out the 10K lines of JSP taglibs).

    PS - any reason why people persist in seeing some opposition between an "IoC" framework and one based on "pure Java"? In my mind the whole function of IoC is to maximise the use of pure Java.
  38. Aranea[ Go to top ]

    Given RSF will probably someday be given a superstructure of a "heavy" model, I would say Aranea-over-RSF looks like a better fit than Wicket-over-RSF if only because i) you have more formality as regards how components cooperate, and ii) have given rendering comparatively little attention and are happy to palm the job off to someone else (currently a bunch of JSP taglibs). Aranea-over-IKAT might well not only be quite achievable but even productive since if there's one thing you do need it's a better rendering model (than JSP).

    Well, as our mission statement says -- we're ready to integrate :) And JSP has it's uses in large EA building, when you want to hide all of your design behind custom tags. We definitely will not build ourselves any templating engines, but much rather integrate with other frameworks.

    And our servlet dependencies are actually even less, since many classes in the "servlet" package do not actually depend on servlet container. Just there is currently little point to separate them.
  39. Well, as our mission statement says -- we're ready to integrate :) And JSP has it's uses in large EA building, when you want to hide all of your design behind custom tags. We definitely will not build ourselves any templating engines, but much rather integrate with other frameworks.
    After some discussions at this end I do see how the JSP model makes sense in this scenario - since the JSP structure allows end-user configuration of use of modular components, and with use of "commodity labour" in that a large shop would find it easy to fill a position for a coder dealing with taglibs in this way.

    This sheds light on another somewhat neglected area of webapp technology, in that the social and environmental impacts of a technology are often at least as if not more important than the specific technical arguments.

    RSF stems initially from a community that is somewhat differently organised - rather than the end product being a single app that is constructed once just before delivery, we face a strong separation between not just one but potentially many UI teams handing down usability requirements on differing instantiations of the same app, but with a much lower "commoditisation" of developer labour. As a result there is a high premium on separation between presentation and content, and a low premium on opaque modularity - a preference for the kind of fine-grained "endlessly decomposable" modularity that Spring is promoting.

    An extension of the previous comment is that the current fragmentation of the webapp framework market is as much to do with the lack of understanding between developers of the relations between requirements in different spaces, as it is to do with specific technical/structural/"code quality" arguments.

    Probably the best way to supply a "JSP-style" modularity within RSF would be to extend the XML-component style of development to allow embedded EL references to ViewProducers configured in the Spring context. This would be quite easy, but noone has asked for it yet :P RSF modularity is always going to be at the ViewProducer level rather than at the level of "components", and once this is achieved there will be the additional benefit of separating "view component configuration" from presentation style, as these are currently inextricably mixed in the JSP model. But indeed, for clients who expect only to make one-off or infrequent decisions as to UI elements, this separation is much less important.

    And our servlet dependencies are actually even less, since many classes in the "servlet" package do not actually depend on servlet container. Just there is currently little point to separate them.
    Actually I counted the coupled lines by looking specifically for "import javax.servlet" lines so the 4000 line figure should be accurate, irrespective of the package naming. You can see my methodology on my Minimality page - while I fully accept that raw LOC is always going to be an artificial measure, not fully reflecting all sorts of realities such as commenting styles and general code quality, I think it is a very useful and quick "order-of-magnitude" indicator of general strategy and bias.
  40. RSF stems initially from a community that is somewhat differently organised - rather than the end product being a single app that is constructed once just before delivery, we face a strong separation between not just one but potentially many UI teams handing down usability requirements on differing instantiations of the same app, but with a much lower "commoditisation" of developer labour. As a result there is a high premium on separation between presentation and content, and a low premium on opaque modularity - a preference for the kind of fine-grained "endlessly decomposable" modularity that Spring is promoting.

    Component style development with JSP also allows you to reuse the same components in different, yet connected applications (which may well have different designs). This is one of the requirements for Aranea. I see that one needs HTML-style templating for public applications, with relatively few use cases and a complex GUI layout/behaviour.

    High separation between presentation and content typically means much more work for the programmer :)
    Probably the best way to supply a "JSP-style" modularity within RSF would be to extend the XML-component style of development to allow embedded EL references to ViewProducers configured in the Spring context. This would be quite easy, but noone has asked for it yet :P

    And the lack of understanding starts :) We chose JSP mainly because most of the people know how to write use them and write custom tags.
    Actually I counted the coupled lines by looking specifically for "import javax.servlet" lines so the 4000 line figure should be accurate, irrespective of the package naming. You can see my methodology on my Minimality page - while I fully accept that raw LOC is always going to be an artificial measure, not fully reflecting all sorts of realities such as commenting styles and general code quality, I think it is a very useful and quick "order-of-magnitude" indicator of general strategy and bias.

    OK. Though it was never a priority to completely separate Aranea from servlet API. The programmer never sees it and the internal dependencies are all localized, so we can refactor them at any time. The core is completely independent from the servlets.

    The fact is that we're planning to run Aranea in different environments as well, so at some point we'll abstract the servlets away completely.
  41. High separation between presentation and content typically means much more work for the programmer :)

    Yes, I agree completely. RSF is designed for an environment where the greatest bulk of maintenance and development costs are expected to be *external* - that is, though perpetual costs incurred through requested reconfiguration from deployers and end users, and not *internal*, that is through the application development itself. The economics of RSF design aim to minimise developer effort with respect to arbitrary large external loads of this kind. Although I think the generally programmer-centric mentality of programmers lead them to believe that fewer projects are of this kind than they really are :P

    For projects where this is not the case, other technologies will most likely be appropriate, especially for apps with shorter lifetimes and project lifecycles, and those without a project team specialised into clear "designer" and "coder" roles &c. I do think that taking this structural "high ground" tends to produce a more clearly structured and tractable framework though, as well as more maintainable and testable apps. But naturally this depends on one's point of view :P
  42. RSF is designed for an environment where the greatest bulk of maintenance and development costs are expected to be *external* - that is, though perpetual costs incurred through requested reconfiguration from deployers and end users, and not *internal*, that is through the application development itself.

    Well, Aranea main goal is to support all kinds of environments by encapsulating common functionality. We do plan to support also the more lightweight case with stateless services, and we even have a couple of simple example made using them included in the distribution (see examples/service*). More likely we will use them as the base to integrate with a lighweight view framework (not unlike RSF). But we haven't really investigated this area in detail, since our first priority is to make a final release of what we have.
  43. Ah, forget it! Just use Seam![ Go to top ]

    Stop wasting time!

    http://www.jboss.com/index.html?module=bb&op=viewforum&f=231

    You Wascals, you!
  44. Ah, forget it! Just use Seam![ Go to top ]

    Bump!

    Facelets...
  45. This sounds very interesting. I like the idea. To me, it is worth looking into.

    This could be an alternative that I would consider for shops that will never use JSF.
  46. This sounds very interesting. I like the idea. To me, it is worth looking into.This could be an alternative that I would consider for shops that will never use JSF.

    I really like the idea of a reimagined JSF written using the Spring style of development.
  47. no state?[ Go to top ]

    You keep talking about not having state.
    But you must have some data between request are you storing that in the page itself?
  48. Client-side state[ Go to top ]

    You keep talking about not having state.But you must have some data between request are you storing that in the page itself?

    Yes, the "core" RSF state is held in a set of "bindings" which in HTML are encoded as a set of hidden form fields. While there's nothing particularly remarkable about this approach, in RSF these bindings have a quite straightforward (and highly predictable) form and would be quite amenable to manipulation by Javascript/AJAX technologies e.g..

    For multi-request flows, RSF does currently store "conversational" state at the server end but the configuration for this is extremely flexible since this state is (or can be) represented in a "trivially" serializable form - i.e. "bean/XML-serializable" as opposed to "Java-serializable". Client-side conversational state will be supported in a future release.
  49. Client-side state[ Go to top ]

    ahh so every link is a submit of a hidden form?

    What about this:

    i have 2 or 3 tables in one page. All tables are pageable and sortale.
    Now i click first page 1 and i sort column 3 and then navigate to page 4

    then i click table 2 and sort column 1 then navigate to page 7

    Then i click on a edit link on one of the rows that is not visible on page 7.

    How fast can you build that stuff? keeping everything at its place ofcours so table 1 still is sorted by column 3 and sits on page 4 when i visit page 7 of table 2 where i click the edit link to edit the object under that row.
  50. State and stuff[ Go to top ]

    No, every link is not a submit of a hidden form. Like JSF, RSF makes a clear distinction between UILink triggering an idempotent operation and a UICommand triggering a non-idempotent one (see, I even kept the names so as not to confuse people :P)

    What you actually do with all this weird multi-page multi-table state is entirely up to you. If the information is in the URL, it will be honoured on the link. If the information is not in the URL, it will be somewhere with some semantics that you endowed it. You may for example put it in a flow scope - based on the Spring Web Flow concept of a flow, or the Seam concept of a conversation, this is a token-identified scope with user-defined lifetime (possibly actually stored in a Session but possibly not).

    I have no real idea what sort of lifetime semantics you are actually wanting on these bunch of tables/pages, but it sounds to me that you are working with some kind of session scope concept. With request-scope IoC at your disposal arranging and configuring this is not terribly hard. It's worth bearing in mind that there is no "Table" component in RSF per se (regarding UIData as one of JSF's greater mistakes). In RSF this sort of stuff is achieved by writing "for" loops and calls to Collections.sort() (or the Hibernate equivalent) - although I may well throw together some small classes at least on the ViewParameters side to make this sort of thing a bit more streamlined for 0.6.2.

    Btw, I can't help notice that I have 3 of the core Wicket team tilting at me in this thread now - can we expect Jonathan to put in an appearance soon? :P
  51. State and stuff[ Go to top ]

    Btw, I can't help notice that I have 3 of the core Wicket team tilting at me in this thread now - can we expect Jonathan to put in an appearance soon? :P

    We felt you might like some discussion. It was all in the article ;)
  52. How you sort or go through the list in the backend is not importand to me. That is just java.

    What i am curious in is when you have 3 tables and you sort or page in one table what happens with the other tables? How and where is that state?

    You say request scope IoC thats fine. But how do the other tables where you didn't do any action on get there state?? I don't want those pages to suddely change there appearence/data because i do sort in another.

    It is not a matter of wicket can do that or does it automaticly for you and X not i am more interessted in how X or Y does it. So maybe i can borrow some features... :)
  53. State and Scoped IoC[ Go to top ]

    I think the answer in this case really does have to be "it's up to the developer" - and ideally the developer should have to go to as little work as possible to implement whatever scoping model they want. It *has* to be up to the developer (and deployer) because the details of these decisions reflect the tradeoffs that your clients (end users, and administrators) require, between state consumption and interface usability.

    It's quite easy to imagine one model where admins of a very high-volume site have insisted that ALL state must be in URLs, and hence your sort/page operation on one page is completely lost once you return to the first one (assuming you don't do it with the back button). On the other hand usability requirements MAY have dictated that this state is stored with a more or less persistent scope. For example it may be put simply in an HttpSession and be semi-durable, or it may even be entered into some completely persistent user preferences store. Given that these are decision that should be part of end-configuration by clients/deployers, a framework should not attempt to fossilize the consequences by making it particularly easy to put the state in one place or another. The point I was making above is that "heavy-component" frameworks (or to use a more complimentary term "Java-natural" frameworks) tend to bias this decision by making it much more idiomatic to put the table state, for example, in session or other quasi-in-memory scope, at the expense of making it harder to put it in other places (in URLs, in database tables, or in interpretable parts of client forms).

    So, the other interesting discussion here relates to "to what extent" this state represents a framework dependency. The RSF model is as far as possible to palm off these issues onto the developer, whilst putting as many tools in his hands to make these easy to resolve. In general it is easier to move this state about if i) it is an injected dependency of the producer, and ii) it is as "trivially" serializable as possible. To answer ii) - more serializable things are things that form a) shallow object hierarchies and b) setter/getter POJOs (or "peas") with no "interesting" semantics/behaviour.

    To turn to i), this is where IoC comes to the fore - the point is that the ViewProducer responsible for generating the views for each of these pages is "opaque" to RSF in that it simply represents an interface which produces components at a particular point in the request lifecycle. Whereas in fact the state that it uses to inform its decision could be injected into it from any scope - request scope, session scope, persistent scope, you name it.

    NB, I've just learned that an important innovation squeezed into Spring 2.0 at the last moment is "multi-scope" IoC - as well as singleton and non-singleton scope, the bean syntax will be extended to allow request, session and other scopes to be declared. I think this won't resolve the efficiency considerations I mentioned with request-scope Spring, but it will certainly make answering questions of the sort you're asking a lot more idiomatic. I.e. it means that switching from one source of state to another is just a matter of changing configuration and not code (ideally). Which is how we want it - deployers of your app are not going to want to change your code.

    So, sorry not to give a specific answer that "RSF does it like this" because I think the real answer is to somewhat "unask the question"? This is exactly the sort of decision that it's a fatal mistake for a framework to try to second-guess or anticipate, but simply to leave the door as open as possible for any solution that may become necessary.
    And as I see it, a some form of flexibly-scoped IoC is the openest kind of door we can think of right now. Trying to put a specific answer to this question *in* the framework will eventually lead to a framework that looks like JSF :P And I know you don't want Wicket to end up like that :P

    Cheers,
    Antranig.
  54. The presentation layer of RSF is based on a fast and minimal pure-HTML templating engine, IKAT. RSF might therefore be of interest to users of Wicket, for example, who are irritated with Wicket's heavy-component architecture and lack of respect for IoC idioms.

    I am xtrmly annoyed by spring programmers calling others heavy.

    if(Spring == JEE made easy)
    {
        Wicket and some others = development made easy;
    }