Hi Mackram, It's great that you are trying to solve this problem. I started on a solution a while back, but ran out of time to actually refactor the Weblocks code base. My code is here: http://bitbucket.org/saikat/weblocks-saikat/ (it seems you have already found it though) and there is some previous discussion about it here: http://groups.google.com/group/weblocks/browse_thread/thread/b4a835d9510d9285/012d70112241f587#012d70112241f587 . But basically, the views being singletons thing is pretty much acknowledged as a problem (someone should correct me if I am wrong), and what you are suggesting - making views a mapping between models and widgets - is pretty much the solution I was trying to implement. If you want any help getting through my new code or want to just bounce ideas about the view refactor, please contact me - I still don't have time ta actually get the code to something fully unit tested and stable, but I would love for someone to follow through with it. Below is an E-mail I wrote to Leslie a while back on the current state of the code in my branch:
> I just pushed the changes I had made so far to > http://bitbucket.org/saikat/weblocks-saikat/. Basically the state of > the code right now can largely be gleened from the asd file. My plan > of action was: > > 1) Go through and get all the widgets working again with the new view > code. I started this and was in the middle of refactoring dataform. > I was going to change things to make a form widget that is essentially > what quickform was, having a "dataseq" widget that just displays a > view's data in a list, and dataform would use these two widgets. You > can see the beginnings of these in data-editor.lisp. Essentially, I > want to move all the display code that used to be in views up to the > widget layer, and this class structure made a bit more sense to me > than how it is currently. > > 2) As I am refactoring widgets, I would add on features to the views > that seem necessary. > > 3) Do a comparison of features between views and views-old to see > which ones should get ported over after getting all the widgets to > work. > > I have made the basic view classes and was working on refactoring the > widgets (currently working on the form widgets). If you want, I can give you > admin access on my repository if > you want to just keep it as the fork for this refactor. Thanks for doing this =). -Saikat On Sun, Jul 5, 2009 at 2:22 PM, Mackram<[email protected]> wrote: > > So based on Lesile's suggestion the issue of Views & widgets seems to > be one of immediate need so I took a quick (or maybe too quick) look > on the form and code for these two entires and there are a few things > I am not sure I understand. > > Mainly my question resides on why a view is not simply an abstraction > of a set of composite widgets? My understanding is that views are > singletons at the current implementation while if they were simply > made up of widgets then they themselves would no longer be > singeltons. > > So before I embark on this task I would like to know why the choice to > build views separate from widgets? Are there any set of > functionalities that result from the current design decision and are > they needed to be preserved? > > Thanks for the help and looking forward to this. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
