"Leslie P. Polzer" <[email protected]> writes: > On Jan 6, 7:35 pm, Jan Rychter <[email protected]> wrote: > >> I disagree here -- I don't think we should worry about backwards >> compatibility, because there is so little to be compatible with. After >> all, we can always E-mail both users of weblocks and have them change >> their apps, right? :-) > > Don't take this too lightly. I have two important apps built on > Weblocks, > you, Yarek, nunb, Robin and Ian each have one... > > Backwards compatibility should not keep us from implementing cool/ > clean > things, but let's try to achieve at least a little bit of it.
Ok. But I'd rather design cool things first, and then figure out whether they can be backwards compatible, than the other way around. I do not think weblocks is mature enough to worry about compatibility yet. And I certainly do not think the current design is good enough to warrant keeping it just for the sake of backwards compatibility. [...] >> The more I work on applications, the less I think of scaffolding. In >> fact, I just found that I can remove all the scaffold declarations in my >> application, because I had to override everything anyway. > > Scaffolding is nice to get something up quickly. Think agile. > > >> This might be different for people that write apps in English, but in my >> case I _never_ want to use my data model field name as a label. > > I don't consider that a real reason since we're working on i18n > support > anyway. What I meant is that in order to specify view labels I need to list all the fields anyway. So really all scaffolding can possibly buy me is a guess that if a field is of :type string then I probably want an input presentation. Even then I often want extra arguments. And if I do use scaffolding I have to worry about hiding the fields I do not want to see (id, join slots, etc.) And even if scaffolding were smart enough to figure out my join slots and present them as dropdowns or checkbox lists, I would still need additional annotations to tell the views which field to display in these presentations. >> I believe scaffolding is complex, difficult to get right, sucks in huge >> amounts of developer effort, and provides little real-world utility >> except for small demos in English. > > We can neglect it until the end and then see how difficult it would > be. > > >> > 3. Inheritance must be working and customizable. We should also try to >> > offload inheritance stuff to CLOS to get rid of the ugly machinery >> > currently employed. >> >> Do you need view inheritance or view encapsulation? > > Do you mean composition? If yes: > > Composition is way more important than inheritance, but inheritance > can be pretty useful, too. Yes, I meant composition, as in one view inside another. And I was curious, because I never actually encountered an inheritance use case, except for inheriting from scaffold views. --J. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
