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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
