Client side caching: Typical omission in server side component models?

It seems like a simple problem, but it is not (to day, I have not been able to find a way to do this without complex Javascript coding):

1. You have chained comboboxes: County and State.
2. You select USA in the Country combobox, and its 50 States are loaded in the States Combo (roundtrip to the server to fetch them)
3. You select Mexico in the Country combobox, and its 32 States are loaded in the States Combo (roundtrip to the server to fetch them)
4. Now you select USA in the Country combobox again... how do I tell the server side component framework that I do not want it to go to the server for them, since it went for them the last time I selected USA, I want it to use that as a cache and do not go for them until I tell it to do so?

I provided this use case as just one illustration of a broader class of client side caching scenarios, support for this kind of scenario might not be need for all use cases, I might not be needed, for example, for user self-registration... sadly, I do not build that kind of application where I work now, the kind of application I have to build is the kind where the UI is used repeatedly: Yes, I build those dreaded "enterprise level" applications used internally by a big organization.

This kind of optimization might seem silly for the typical web application where the user rarely uses the same form more than once, but for enterprise applications, this behavior can be the difference between an application that is perceived to be responsive and useful, and an application that is perceived to be cumbersome and useless.

This can not be done with “user code” in AribaWeb. It can not be done in JSF, and it can not be done in ASP.NET. But is extremely easy to do if you code in JavaScript and use ExtJS, or Cappucchino.

I wonder... Is this problem really impossible to solve in a declarative way using server side component models? is this really the insurmountable frontier for server based frameworks? or could someone create a trick that made this work?

Inversion of re-render (subscription based re-rendering): Why it can not be this way?

Anyone that has used Richfaces knows that to rerender something, one needs to refer to it by id.

Now, this is (in my opinion) an useful approach but also a very limited one, specially if componentization and code reuse are important goals during development

Lets say I build a page (lets call it root page), that has a subview with a modalPanel, that includes a facelet component, that has a subview with modalPanel that includes another facelet component, and, when something is done here, I one another control, in the root page to be rerendered

Now, I could of course pass along the ids of the component I need to be re-rendered, but... what if I need another component to be re-rendered too? do I pass along its id too? and what if the other component is also inside (a different) subview with a modalPanel, that includes a different facelet component... then all this id "passing" gets really messy, and creates dependencies in components that could otherwise be decoupled... and to make things worse, using meaningful ids in JSF is not considered a good practice, because meaningful ids (specially if used in name container like the subviews) rapidly increase the size of the pages (because they concatenate to ids of all the contained controls), contributing to bandwidth waste .

Now, I have a proposal, what if re-rendering were to work in an "inversed" way: instead of "A" saying that it will re-render "B", we say that "B" will be re-rendered when something (maybe "A") says so by broadcasting event "C".

This would mean that "A" no longer needs to know the name of "B" and "B" wouldn’t need to know the name of "A" either, it would only need to know that it should re-render itself it something, somewhere broadcasted the event "C"

Am I making sense here? Is this doable? Or am I not seeing a major limitation in JSF technology that prevents this from being built? (I am no expert in JSF, so I really can not say, but I do know that an event subscription based re-rendering engine would be a really nice tool to have)

Ruby is younger therefore better than Java?

I wrote this as a response to From Java to Ruby: Programmer's view, but I couldn't post it because of a bug in that site, so I decided to post it in my own blog:

Isn't this a simplified view of the advantages of Ruby over Java? For example the lack of choice in Ruby means that if the "one Ruby way" to do stuff is not good for you project... you will have to go to other technologies (Java for example). And that can happen pretty often:

• Hibernate has many more options for integration with legacy databases than Ruby's Active Record... almost all databases now have JDBC drivers (you can not say the same about Ruby database support).
• Spring offers integrated transaction handling that makes it possible to switch from JDBC transactions to JTA transactions without changing a single line of Java code (you just need to modify around 5 lines in an XML file) what is the equivalent for that in Ruby?
• Calling stored procedures is not that easy with Ruby... what is the equivalent of HQL (JPAQL) for Ruby... can you honestly say that it can handle all the special cases HQL can... and with the same efficiency?
• With java I can build a web application GWT style, JSF style or plain JSP style... and each style has advantages and disadvantages... do I have all that power with Rails? (Of course, those frameworks can be re-built in Ruby, but the question is, do I have them now?)

I think you are right when you say that it's healthy to start with a clean slate and rebuild based on a cleaner, simpler foundation, but before saying that the new foundation is actually better than the older one, you have to be sure that your new foundation is actually capable of handling all the special cases the old foundation was capable of handling... or remember that maybe if you remove all the abilities the old foundation has to handle special cases you might end up realizing that your new foundation is just a replica of the state that the old foundation had when it was younger. (And even then the older foundation has the advantage that you can use it as it was used in the past, but you can not use a new foundation as it will be used in the future)