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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
