> It is not like the cache is optional for dispatchers, given that not all > requests have URIs attached, and we would surely like to be able to > dirty them (which we cannot do in dev, IIUC).
What do you mean by "dev"? Marking widgets as dirty works in weblocks-dev and weblocks-dev-modern-dispatching. > (I have less to say about your other selector proposals. I don't really > like how they are in dev or modern-dispatching.) I think we all agree on the restructuring of the selector/navigation part then. > As I have mentioned above, I believe this only complicates things beyond > what you can already do with dispatcher and the default > widgets-ephemeral mode. Speaking of which, I don't like the current dichotomy: I can either choose fresh generation of a widget (ephemeral) every time and lose AJAX updates, flows and so on or have it cached all the time for the whole session. I'm sure we can find something better. > Obviously, not all information can be managed in this way. However, it > does cover a great deal of it. The danger of talking about "admin > interface" is that to the Weblocks user it says "you're supposed to do > it like in Django", which is a very poor substitute for the power to > create intuitive interfaces that Weblocks offers. I agree with Jan here that it should be possible to choose to separate the administration from the rest. It's sometimes desirable to do this. We can show both approaches in the upcoming user guide and give HCI advice. Leslie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
