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]> 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] 
>> > wrote:
>>
>> 2008/11/18 Aurels <[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://makerlab.com 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to