Hey, apologies for not really speaking clearly here - I have to go on stage soon to present something else.
Anyway - here's some argument on the idea of flattening slices away, and kind of contextualized by some previous work which I did when I first learned ruby a while back: http://appwiki.org http://makerlab.org/projects/show/appwiki To be more precise. Here is a base component: http://code.google.com/p/applicationwiki/source/browse/trunk/base/base_controller.rb And this user component subclasses the base: http://code.google.com/p/applicationwiki/source/browse/trunk/user/user_controller.rb Now note this was when I was first learning ruby... so it is not terrific work. But I was able to *VERY* quickly build out several applications, each only slight variations of the previous - by using this approach. Instead of asking merb to generate me yet another set of mvc files for a particular slice of functionality - I would just ask for an inheritance of an existing component.... This whole idea failed due to lack of interest. But I'm still personally interested in just trying to advocate for the idea of the flattest possible slices, and allowing for inheritance. Apologies again if I am unclear... this is about the best I can do to try convey the idea without belaboring it to death. - me On Tue, Nov 18, 2008 at 5:17 PM, Anselm Hook <[EMAIL PROTECTED]> wrote: > Granted, well my ignorance is more a lack of time to be totally clear but > I did write an alter framework that specified my ideas as an actual > implementation - see http://appwiki.org - I applied several ideas in this > framework pushing mostly against rails which I found very clumsy. Will try > be more clear later when time permits. > > Sent from my iPhone > > On Nov 18, 2008, at 4:47 PM, Julian Leviston <[EMAIL PROTECTED]> wrote: > > Hi Anselm, > I'm not too sure you understand MVC very well. > > Rails OOP is fairly "broken" and "magic" IMHO, therefore it encourages such > malformed views on how an application's logic needs to be broken up into > Model, View and Controller: things "connect" automatically in the background > (which is VERY useful, if you've ever tried to roll your own). > > The whole "Resource" thing, if not clearly presented (and this *IS* very > complicated stuff), tends to encourage a retarded understanding of the > relationship of the classes involved in the entire landscape of the problem > domain. > > Magic is powerful, but has the potential to really burn muggles if there > are no wizards around (okay, I'll put the Harry Potter analogy away now). > > It disturbs me, slightly, for example, that you appear not to know how to > subclass a Ruby class, and yet you are making suggestions to core developers > of a framework! > > I think that there may be a tendency by the core team to take suggestions > from EVERYONE, which is okay, but perhaps they would do well to take > suggestions from people who demonstrate a little that they know what they're > talking about AND what they're suggesting first. > > Perhaps, Anselm, you would do well to explain EXPLICITLY and in detail how > you would like this to operate, and if you have an actual requirement for > this feature, then to give us the real context the query and issue came > from. If you can't demonstrate its reality, then perhaps it's not a valid > concern yet! > > Julian. > > On 19/11/2008, at 11:32 AM, Anselm Hook wrote: > > granted i accept many of those args - just use classes or make a gem > etcetera, > > but to qualify the argument a bit - just to make sure that i am > communicating clearly: > > i want to subclass views also, so if i have a slice with a model view > control like > > class user << default merb controller of some kind > def login > render # ---> this goes off and connects to > app/views/users/login.html.erb > end > end > > i should be able to do subclass the entire behavior, like, > > class betteruser << some kind of subclass of the other > model,view,controller of user > def favoritecolor > render > end > end > > and just cite the entire other slice without a non dry style copying and > pasting of the layout templates into a new folder... in the above example i > wouldn't even express the 'login' capability at all again - it would be > inherited - including the view. > > - anselm > > On Tue, Nov 18, 2008 at 2:22 PM, Julian Leviston < <[EMAIL PROTECTED]> > [EMAIL PROTECTED]> wrote: > >> It sounds like you just want a bunch of classes, so why not create a bunch >> of classes? >> Julian. >> >> On 19/11/2008, at 7:06 AM, Anselm Hook wrote: >> >> my criticism of slices is that they enforce the mvc folder paradigm that >> is so tedious to browse through and create directory and navigation >> nightmares - why not conflate the controllers, views and model into a single >> folder? it would just be an acknowledgement that this is a fundamentally >> different pattern that is not quite so mvc centric but rather component >> centric. >> >> another criticism is that i cannot subclass a slice... why do we leave the >> land of object oriented design and not support inheritance once we reach the >> level of components? >> >> - me >> >> On Tue, Nov 18, 2008 at 11:50 AM, Michael Klishin <<[EMAIL PROTECTED]> >> [EMAIL PROTECTED]> wrote: >> >>> >>> 2008/11/18 Aurels < <[EMAIL PROTECTED]> >>> [EMAIL PROTECTED]>: >>> > The "lack" of slices on github is probably due to the fact that merb >>> > is really young ;) >>> >>> I think slices authors may want to have a look at projects mentioned >>> at djangoplugables.com >>> -- >>> MK >>> >>> >>> >> >> >> -- >> anselm 415 215 4856 <http://hook.org>http://hook.org >> <http://makerlab.com>http://makerlab.com <http://meedan.net> >> http://meedan.net >> >> >> >> >> >> >> > > > -- > anselm 415 215 4856 <http://hook.org>http://hook.org <http://makerlab.com> > http://makerlab.com <http://meedan.net>http://meedan.net > > > > > > > > -- anselm 415 215 4856 http://hook.org http://makerlab.com http://meedan.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" 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/merb?hl=en -~----------~----~----~----~------~----~------~--~---
