My two cents. I'm running off a fork of weblocks from the late summer - it was stable enough, I had incompatible customizations, and I didn't have time to keep up with the churn.
I was underwhelmed by the view design at that time. It seems to be trying to over-generalize something that has such a large and complex parameter space (conflating DB access, visual layout, user commands, presentations, etc) that the API simply become too unwieldy. I found myself throwing so many custom functions at the problem and bypass all the scaffolding, that it was easier to just write custom widgets. Except for a relatively common use of quickforms, and a few list views, we built an entirely custom set of widgets and presentations for displaying sequences, data, and forms. I agree, though, that views and scaffolding are nice for prototyping or for low-level admin interfaces. Navigation, interactions among widgets on the tree, friendly URL handling, and dealing with changes in language, authentication were all quite frustrating at that time. I haven't looked at the current tree in quite some time so I'm not sure what state it is in now. Is the view system essentially separable from the widget/navigation/action/URL core? It will be quite a bit of work to upgrade to a new tree, but I'm so out of date now that it really doesn't matter so I vote for 'doing the right thing' and don't mind any incremental extra work to update. I'd like to use the view system where appropriate, and maybe identify some nice tools to use when it isn't. Just let us know when things are stable enough that we should consider upgrading! In fact, I would like to request/recommend that we look at tagging a stable point in the tree as a kind of interim release once the nav stuff and a version of the view functionality settles down. It would give everyone a common place to fork from, provide some community consensus on the core functionality, and make folks like me feel better about upgrading and perhaps starting to contribute code again! Ian On Jan 6, 2009, at 3:27 PM, Jan Rychter wrote: > > "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 -~----------~----~----~----~------~----~------~--~---
