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)