MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]

[Stefano Mazzocchi <st...@apache.org>]

Nicola Ken Barozzi wrote:

> Let's remember that flowscript is a potential liability in a sense that
> it can be really abused in doing what you and I know it shouldn't do.

Agreed. In fact, as others already pointed out, it might become a
gateway to abuse and concern overlap. But I think this could be said of
actions.
 
> BTW, just a RT... this means that we would have MVFC: model, view, flow,
> controller... :-?

Finally, you are scratching the surface and looking into it: there is no
MVC on the web. MVC assumed a stateful environment. The reason why
people are so excited about MVC is that is the most ovbious instance of
the SoC metapattern.

(yes, it's already hard enough to abstract to patterns: abstracting to
patterns of patterns is *much* harder, even for trained programmers).

So, MVC is just one of the possible ways you can separate concerns and
(I keep on saying this), it's *NOT* the best way to implement web
applications, no matter how hard you try.

The reason: http intrinsic statelessness.

So, let's dissect MVC:

1) view is the concern that everybody identifies easily. It doesn't
matter what technology you use for this, but template systems (think
SSI) were invented the day the dynamic web was born.

2) model is harder. For GUI widgets it's easy: it's the OO abstraction
of the concept implemented by the MVC pattern (say: a button, a text
area, etc..) What is the model of your "webmail"? In GUIs, the MVC
granularity is for the single widget, what is the model granularity for
web applications?

So, first problem: what is the granularity of MVC? For GUIs is the
widget (if you disagree, tell me: what is the "model" of photoshop?),
for webapps what? pages?

No, pages are too small and webapps too big. Then what?

3) controller is a nightmare: where is it? MVC creates a nice SoC
because:

 - view -> presentation concern
 - model -> data concern
 - controls -> logic concern

but it assumes:

 - granularity is coherent
 - state transitions are stateful

I hear you saying: it's up to the implementation to add state to the web
application transparently. It's easy to do.

Sure, but you are still left with the problem of identifying which is
the best granularity for those MVC realms. Pages are too small (can you
have a different controller per page? doesn't make sense), webapps too
big (can you have a single model for the whole webapp? nah), sessions
too heavy (can you have a single view for each session? well...).

Result: those who say "let's use an MVC framework" are indeed saying
"let's use a framework that allows us to separate concerns", the problem
is that they are biased to perform a specific separation between
concerns that cannot be applied on the web AS IS!

Now you could ask me: what is the best SoC model for the web?

How do I know!?!

I would be *very* egocentric from my side to say: look, you should
decouple your application like this and this and this. How do I know?

The only think I think I can safely say is: identify your concerns and
work to separate them.

In some cases, you might even find that MVC is perfect for the job.
Great, use it. But that's the difference between Cocoon and the rest of
the world:

 1) Cocoon is about applying SoC on the web

 2) the others webapp frameworks are about applying MVC on the web

Since MVC is a very specific implementation of the SoC metapattern, you
should be using those MVC-based frameworks only when MVC is good for
you: unfortunately, not many times since it forces you to follow
patterns that weren't invented for the web.

So, I think you now understand why

> MVFC: model, view, flow, controller... :-?

is a terrible idea: the concept of flow partially overlaps with the
concept of controller. But 'flow' is more at the application level: you
wouldn't be able to state the flow of a GUI widget, but you would be
able to describe the flow of photoshop operations in terms of different
widgets.

See my point? MVC works well on small and defined components, but the
web component (a page) is too small. We need to find something else, for
example:

 - pipelines
 - business logic
 - transitions

but I won't even start to discuss this since I know that each one of us
will have a different opinion on the subject.

Just one thing: let's stop citing MVC as a good practice for web
development. It's not, let's fact it once for all and move forward.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]

[Ovidiu Predescu <ov...@apache.org>]

On 6/24/02 8:23 AM, "Stefano Mazzocchi" <st...@apache.org> wrote:

> Nicola Ken Barozzi wrote:
> 
>> Let's remember that flowscript is a potential liability in a sense that
>> it can be really abused in doing what you and I know it shouldn't do.
> 
> Agreed. In fact, as others already pointed out, it might become a
> gateway to abuse and concern overlap. But I think this could be said of
> actions.
> 
>> BTW, just a RT... this means that we would have MVFC: model, view, flow,
>> controller... :-?
> 
> Finally, you are scratching the surface and looking into it: there is no
> MVC on the web. MVC assumed a stateful environment. The reason why
> people are so excited about MVC is that is the most ovbious instance of
> the SoC metapattern.
> 
> (yes, it's already hard enough to abstract to patterns: abstracting to
> patterns of patterns is *much* harder, even for trained programmers).
> 
> So, MVC is just one of the possible ways you can separate concerns and
> (I keep on saying this), it's *NOT* the best way to implement web
> applications, no matter how hard you try.
> 
> The reason: http intrinsic statelessness.

I think Web applications are in fact stateful. I don't think the inherent
statelessness of the HTTP protocol changes this fact.

Comparing with a GUI application, you'll find lots of similarities, where
mouse clicks and keyboard clicks are translated into events which are sent
to the application. GUI applications have a run loop, the equivalent of the
HTTP server, which just listens for new events and dispatches them to the
appropriate receivers.

The fact that HTTP is not stateful is by now worked around with cookies or
other techniques which hide this aspect, and make it irrelevant. The end
result is that Web apps are comparable with GUI apps in terms of model.

> So, let's dissect MVC:
> 
> 1) view is the concern that everybody identifies easily. It doesn't
> matter what technology you use for this, but template systems (think
> SSI) were invented the day the dynamic web was born.
> 
> 2) model is harder. For GUI widgets it's easy: it's the OO abstraction
> of the concept implemented by the MVC pattern (say: a button, a text
> area, etc..) What is the model of your "webmail"? In GUIs, the MVC
> granularity is for the single widget, what is the model granularity for
> web applications?
> 
> So, first problem: what is the granularity of MVC? For GUIs is the
> widget (if you disagree, tell me: what is the "model" of photoshop?),
> for webapps what? pages?
> 
> No, pages are too small and webapps too big. Then what?
> 
> 3) controller is a nightmare: where is it? MVC creates a nice SoC
> because:
> 
> - view -> presentation concern
> - model -> data concern
> - controls -> logic concern
> 
> but it assumes:
> 
> - granularity is coherent
> - state transitions are stateful
> 
> I hear you saying: it's up to the implementation to add state to the web
> application transparently. It's easy to do.
> 
> Sure, but you are still left with the problem of identifying which is
> the best granularity for those MVC realms. Pages are too small (can you
> have a different controller per page? doesn't make sense), webapps too
> big (can you have a single model for the whole webapp? nah), sessions
> too heavy (can you have a single view for each session? well...).

I think the right granularity is the unit of functionality of a Web page. In
the Jakarta world, the closest encounter to this is the portlet idea, which
embeds the whole functionality of a Web page component in a type of
component, that has View and Controller capabilities, and invokes the Model
from its action methods.

We probably need to think along the same lines of this portlet idea. But
instead of the portlet thingy, we should have many smaller components which
are smaller MVC instances composed of their own flow, subsitemap and
business logic, which is able to represent them. This is very close to the
Cocoon blocks idea, at least the way I see it.

> Result: those who say "let's use an MVC framework" are indeed saying
> "let's use a framework that allows us to separate concerns", the problem
> is that they are biased to perform a specific separation between
> concerns that cannot be applied on the web AS IS!

I don't think this last statement is correct. For example MVC has been
successfully applied to Web application frameworks by Apple WebObject's
since 1996. Check out their latest documentation:

http://developer.apple.com/techpubs/webobjects/DiscoveringWO/index.html

Or a rather outdated documentation for WO 2.0 I think, but more technical
and perhaps easier to grab the concepts from, which is available at:

http://www.crust.net/resources/w3/webobjects.html.d/WebObjectsDoc/

Apple, or NeXT at that time, used to sell this stuff for really big bucks
(I'm talking about $50k/license), and they had large customers like Fedex
and Disney Interactive. Of course, WebObjects was much more than that, they
had, and still have, a very nice, fast and productive DB <-> objects mapping
tool.

> Now you could ask me: what is the best SoC model for the web?
> 
> How do I know!?!
> 
> I would be *very* egocentric from my side to say: look, you should
> decouple your application like this and this and this. How do I know?
> 
> The only think I think I can safely say is: identify your concerns and
> work to separate them.
> 
> In some cases, you might even find that MVC is perfect for the job.
> Great, use it. But that's the difference between Cocoon and the rest of
> the world:
> 
> 1) Cocoon is about applying SoC on the web
> 
> 2) the others webapp frameworks are about applying MVC on the web
> 
> Since MVC is a very specific implementation of the SoC metapattern, you
> should be using those MVC-based frameworks only when MVC is good for
> you: unfortunately, not many times since it forces you to follow
> patterns that weren't invented for the web.
> 
> So, I think you now understand why
> 
>> MVFC: model, view, flow, controller... :-?
> 
> is a terrible idea: the concept of flow partially overlaps with the
> concept of controller. But 'flow' is more at the application level: you
> wouldn't be able to state the flow of a GUI widget, but you would be
> able to describe the flow of photoshop operations in terms of different
> widgets.
> 
> See my point? MVC works well on small and defined components, but the
> web component (a page) is too small. We need to find something else, for
> example:
> 
> - pipelines
> - business logic
> - transitions
> 
> but I won't even start to discuss this since I know that each one of us
> will have a different opinion on the subject.
> 
> Just one thing: let's stop citing MVC as a good practice for web
> development. It's not, let's fact it once for all and move forward.

As I said above, I do think MVC makes a lot of sense for the Web world. I
think Cocoon has the right ingredients to make it a really nice and powerful
MVC framework for building Web apps. We just need to see what is the right
mix and recipe for all these ingredients to make a good cake ;)

Best regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: MVC demistified [was Re: [RT] SpitScript - B-Logic that doesn't suck ]

[Nicola Ken Barozzi <ni...@apache.org>]

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
> 
> 
>>Let's remember that flowscript is a potential liability in a sense that
>>it can be really abused in doing what you and I know it shouldn't do.
> 
> Agreed. In fact, as others already pointed out, it might become a
> gateway to abuse and concern overlap. But I think this could be said of
> actions.

+1

>>BTW, just a RT... this means that we would have MVFC: model, view, flow,
>>controller... :-?
> 
> Finally, you are scratching the surface and looking into it: there is no
> MVC on the web. MVC assumed a stateful environment. The reason why
> people are so excited about MVC is that is the most ovbious instance of
> the SoC metapattern.
> 
> (yes, it's already hard enough to abstract to patterns: abstracting to
> patterns of patterns is *much* harder, even for trained programmers).
> 
> So, MVC is just one of the possible ways you can separate concerns and
> (I keep on saying this), it's *NOT* the best way to implement web
> applications, no matter how hard you try.
> 
> The reason: http intrinsic statelessness.
> 
> So, let's dissect MVC:
> 
> 1) view is the concern that everybody identifies easily. It doesn't
> matter what technology you use for this, but template systems (think
> SSI) were invented the day the dynamic web was born.
> 
> 2) model is harder. For GUI widgets it's easy: it's the OO abstraction
> of the concept implemented by the MVC pattern (say: a button, a text
> area, etc..) What is the model of your "webmail"? In GUIs, the MVC
> granularity is for the single widget, what is the model granularity for
> web applications?
> 
> So, first problem: what is the granularity of MVC? For GUIs is the
> widget (if you disagree, tell me: what is the "model" of photoshop?),
> for webapps what? pages?
> 
> No, pages are too small and webapps too big. Then what?
> 
> 3) controller is a nightmare: where is it? MVC creates a nice SoC
> because:
> 
>  - view -> presentation concern
>  - model -> data concern
>  - controls -> logic concern
> 
> but it assumes:
> 
>  - granularity is coherent
>  - state transitions are stateful
> 
> I hear you saying: it's up to the implementation to add state to the web
> application transparently. It's easy to do.
> 
> Sure, but you are still left with the problem of identifying which is
> the best granularity for those MVC realms. Pages are too small (can you
> have a different controller per page? doesn't make sense), webapps too
> big (can you have a single model for the whole webapp? nah), sessions
> too heavy (can you have a single view for each session? well...).
> 
> Result: those who say "let's use an MVC framework" are indeed saying
> "let's use a framework that allows us to separate concerns", the problem
> is that they are biased to perform a specific separation between
> concerns that cannot be applied on the web AS IS!
> 
> Now you could ask me: what is the best SoC model for the web?
> 
> How do I know!?!

hahaha :-)  S**t, I really hoped for an answer, but a good laugh is 
enough for now ;-)

> I would be *very* egocentric from my side to say: look, you should
> decouple your application like this and this and this. How do I know?

Too bad you're not egocentric enough then ;-)

> The only think I think I can safely say is: identify your concerns and
> work to separate them.
> 
> In some cases, you might even find that MVC is perfect for the job.
> Great, use it. But that's the difference between Cocoon and the rest of
> the world:
> 
>  1) Cocoon is about applying SoC on the web
> 
>  2) the others webapp frameworks are about applying MVC on the web
> 
> Since MVC is a very specific implementation of the SoC metapattern, you
> should be using those MVC-based frameworks only when MVC is good for
> you: unfortunately, not many times since it forces you to follow
> patterns that weren't invented for the web.
> 
> So, I think you now understand why

Yup. The point is that if we want to sell Cocoon, MVC is a cool buzzword...

>>MVFC: model, view, flow, controller... :-?
> 
> 
> is a terrible idea: the concept of flow partially overlaps with the
> concept of controller. But 'flow' is more at the application level: you
> wouldn't be able to state the flow of a GUI widget, but you would be
> able to describe the flow of photoshop operations in terms of different
> widgets.
> 
> See my point? MVC works well on small and defined components, but the
> web component (a page) is too small. We need to find something else, for
> example:
> 
>  - pipelines
View

>  - business logic
Model

>  - transitions
Controller


> but I won't even start to discuss this since I know that each one of us
> will have a different opinion on the subject.
> 
> Just one thing: let's stop citing MVC as a good practice for web
> development. It's not, let's fact it once for all and move forward.

It's a good buzzword, and easy to understand.

I still use it, since MVC is usually correct, even for webapps:
- view=what you see
- model=the data
- controller=behaviour

Even if it's not the case 100% of the time, pipelines are the view.
The model is somewhere in the javabeans-EJBs, and the controller is the 
flowscript.
The sitemap is what ties all together.

So it's a 3+1 model, MVC2 (double level controller).

I know it's kinky, but I'm not joking when I say that *ever* *single* 
developer I met aske me if Cocoon is MVC.

And that when showing flowscript, I hear: "Oh, finally Cocoon has a 
controller!".

MVC is not the answer to all needs, but referencing it can make things 
easier to "market" Cocoon and to make it more understood.


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org