I agree with the sentiment of not taking this too lightly. I think you underestimate how significant weblocks is and how many people are monitoring its progress.
Many of us are interested in building apps with Weblocks, just because we don't post regularly doesn't mean we are not interested parties. I have an auction application underway, nothing sophisticated but important to me; that said, breaking changes are sometimes necessary but should be appropriately tagged / branched in the scms (hg) and broadcast. On Jan 6, 11:45 am, "Leslie P. Polzer" <[email protected]> wrote: > 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. > > > > 2. It should be easy to override a single slot of a view. > > > Do you mean after scaffolding? > > General inheritance. > > > 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. > > > 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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
