On Wed, Oct 21, 2009 at 4:45 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > We can go on and on. We need other people input on this. > Do you want input, or relief? Do this for me - take your list of 13 things, and apply a category - what kind of thing is it? on each, with the goal to get the 13 organized into no more than 3 or 4. Then we can discuss if those 4 kinds of behaviors sound like plugin behaviors or not. A starting point might be separating by something, anything that associates things - e.g. those items where data is completely separate from app; those where app database is shared; those things where app data tables are modified (and I will prepare you for throwing those out completely when you get to that ). If someone wants to give input in this context, that would be good. - Yarko > > > On Oct 21, 4:32 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > wrote: > > On Wed, Oct 21, 2009 at 4:15 PM, mdipierro <mdipie...@cs.depaul.edu> > wrote: > > > > > I do not understand. Models, Views and Controller are files. You can > > > encapsulate them in folders. How would you encapsulate them in > > > classes? > > > > Models (data layer), controllers (engineering rules or business rules), > and > > views (presentation layer) are separation of concerns. > > You have them separated by directories / files. > > > > Classes (by definition) encapsulate behaviors (functions), and data. > > > > > Let me put is another way. > > > This discussion has kept a plugin implementation on hold for one year > > > because I think any other implementation is going to be more clunky. > > > > I don't know what that means - I have heard you say / complain that "more > > code would have to change" - which is a sign of design coupling, so the > > natural coupling here is in the directory structure, used to hold all > > structure - it is showing its limitations perhaps. > > > > > I > > > am happy to consider alternative solutions but I want to see a fully > > > working implementation by mid November so we can release plugin specs > > > by end the of the year. > > > > You have this upside down, I think - I want to see the specs (what you > want > > it to do, how you want it to behave) before you start showing me > solutions > > for release. > > > > It is ok to prototype to flush out some aspects, some specs when you > don't > > know - e.g. how would discovery work. But then, back to how this fits > into > > the system - that look is needed. > > > > There is no "on hold" - if implementation were trivial, then you could > just > > code it up. Since this needs thinking specification, LACK of that talk > is > > what has put this on hold. > > > > It can go out in November. Then you will see in practice what it's > > limitations are, and iterate again in a year. Or you can think / specify > a > > little more, have things work a little better, and cut the number of big > > iterations in 1/2 or less. Your choice. > > > > > > > > > We should continue the discussion and you should continue try convince > > > me. I do not exclude I will be working on other implementations as > > > well (that why I do not promise backward compatibility on this yet). > > > > Experience will convince you. Or openness (willingness to try and see > the > > other perspective). > > > > If you do not believe that having plugin_xxx.py files everywhere will > create > > problems, then you will have to experience that. > > > > If the human side of this was not important, then the language (and > aspects > > that get in your way) would not be important either. > > > > But is IS important. > > > > - Yarko > > > > > > > > > Massimo > > > > > On Oct 21, 3:54 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > wrote: > > > > On Wed, Oct 21, 2009 at 3:42 PM, mdipierro <mdipie...@cs.depaul.edu> > > > wrote: > > > > > > > On Oct 21, 3:01 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > > > wrote: > > > > > > On Wed, Oct 21, 2009 at 2:50 PM, mdipierro < > mdipie...@cs.depaul.edu> > > > > > wrote: > > > > > > > > > As far as I am concerned think there are the only rules we need > to > > > > > > > follow: > > > > > > > > > 1) a naming convention: > > > > > > > > > models/plugin_[name].py > > > > > > > controllers/plugin_[name].py > > > > > > > */plugin_[name]/* > > > > > > > > This convention is spaghetti source - it is crap; I do not like > it in > > > the > > > > > > least, and see absolutely no reason to even consider it. > > > > > > > > It will only lead to confusion, and novices learning to have to > > > manage > > > > > all > > > > > > sorts of code they should not be looking at, knowing about the > > > internal > > > > > > details (modularity - remember?!) - and if this is a teaching > system, > > > > > even > > > > > > the more. > > > > > > > > I want to see you just DROP this convention. > > > > > > I'll repeat. It is crap. > > > > > > > > As Thadeus points out (and I only vaguely remember - it may need > more > > > > > > discussion) - Mr. Freeze proposes something more appropriately > > > > > structured. > > > > > > > > Look at it again, more seriously. > > > > > > > I did. Over and over. Let me explain why it is not crap. Think of a > > > > > matrix where the columns are models, views and controllers and the > > > > > rows are functional components like plugins. > > > > > > Then perhaps we need classes - since what you are saying is this > > > structure > > > > (the row/column layout of web2py) is not able to cleanly encapsulate > > > > components / plugins for the programmer. > > > > > > You will have students - even maintainers - looking at applications, > > > > maintaining them, with all sorts of "plugin_xyz.py" files, some in > > > > controllers, some in... > > > > and they will change them - and you will remind them (because it is > not > > > well > > > > encapsulated) to ALSO change the associated models / views when they > make > > > a > > > > change.... AND to remember what they SHOULD NOT do.... AND..... > AND..... > > > > > > I repeat - this is crap! ;-) Really (the smiley is not because I am > > > > kidding, but just that I am not giving way, but trying to add > something > > > to > > > > make this more friendly). It is crap because it will lead to this > in > > > the > > > > systems that go out, so one of two things are likely to occur ---- > the > > > > "plugins" will be confusing, OR people will be tempted to change > them in > > > > innapproriate ways, and it will devolve into nothing more than some > > > fancy, > > > > enabled CUT-AND-PASTE opportunistic code-reuse system (not modular!). > > > > > > Trust me, if it smells like, and looks like ..... it probably is.... > > > > > > > Now we need to represent > > > > > this structure in a filesystem which has a tree like structure. > > > > > > No - YOUR solution has this constraint; I am saying look at the > problem > > > > more, and reconsider your solution again... > > > > and again... and again... until it has the right shape. IF it > suggests > > > > other things that need to be rewritten, and there is a cascade of > that - > > > > while dissapointing, it may be a good thing (not a bad thing). > > > > > > > Again: > > > > > we are trying to represent a matrix as a tree. You want to do it by > > > > > row (one folder for each plugin and models/views/controllers > > > > > subfolders for each plugin). I want to represent it by column (top > > > > > level models/views/controllers and files of subfolders for each > plugin > > > > > within each top level folder). Why I like the second better? > Because > > > > > web2py already has that structure and in fact we have that already > > > > > without changing one line in web2py. > > > > > > You are stuck in the depths of your solution here, so these arguments > > > only > > > > apply there... > > > > > > I would like to see you get out of solution mode for a few minutes, > and > > > take > > > > a 50,000 meter view for a bit before you go back down to that > level... > > > > > > > In order to take the other approach (the one you suggest) you would > > > > > have to represent some parts of the matrix by column (those that do > > > > > not belong to plugins) and some by row (those that belong to > plugin) > > > > > and this would result in real spagetti code in the implementation > and > > > > > it would constitue a major web2py rewrite. In which order should > the > > > > > folders be looked up? In which order should models be executed? > > > > > > > From a logical point of view plugins can be managed as subfolders > and > > > > > that is what admin already does. > > > > > > That is deployment - what about from the developer's perspective - > what > > > are > > > > the implications of this mess there?! > > > > > > Ach! > > > > > > - Yarko > > > > > > > > > 2) models/plugin_[name].py can assume ONLY db, auth, crud, T > > > > > > > > auth, crud, T are gluon defined; that's ok. > > > > > > > > db is an application level variable, so that seems potentially > > > > > problematic, > > > > > > an assumption - this either needs to be NOT shared, or a way for > the > > > > > > application to configure it for plugins is needed. > > > > > > > > > 3) models/plugin_[name].py should define only one global > object > > > > > > > > > plugin_[name]=dict() > > > > > > > > Ugh! > > > > > > > > Well, this is ONE way to do plugin registration so the system > know > > > what > > > > > is > > > > > > there. It's uglly, and brut force. I don't even want to > critique it > > > > > > because, as I've said before, the IMPORTANT point is: > > > > > > > > - The running app needs a way to discover what plugins are > > > available, > > > > > and > > > > > > there must be a way for the plugin to somehow registrer it's > > > presence. > > > > > > > > Now: WHAT are the important things an app / web2py instance > must > > > know > > > > > > about the plugin? > > > > > > > > - version? > > > > > > - name? > > > > > > - is it using / expecting app db connection? > > > > > > - is it creating own db connecntion? > > > > > > > > We should make a big list, and narrow it down to reasonable > things > > > later. > > > > > > > > This has not been done, and is one reason why discovery (and > > > associated > > > > > > problems because of that) doesnt' yet exist. > > > > > > > This is true but at this point I am just interested in making sure > > > > > people can experiment with LOAD and make sure one plugin does not > > > > > interfere with another. What plugins should share is another story > and > > > > > I am not sure I want to dictate that. I can think for example of > two > > > > > different web2py CMSes that may want to use distinct sets of > > > > > incompatible plugins and I do not see a problem with that. > > > > > > > I define "component" a LOADable action of a "plugin". > > > > > > > Massimo > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
