Look forward to see this!
On Oct 21, 5:19 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> I have been writing my own document, going through exactly what you are
> asking Yarko.
>
> Hopefully I can post it later tonight, depending if baseball gets canceled
> or not!
>
> -Thadeus
>
> On Wed, Oct 21, 2009 at 4:50 PM, Yarko Tymciurak <
>
> resultsinsoftw...@gmail.com> wrote:
> > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
