Home » Eclipse Projects » GEF » MVC or PAC
| MVC or PAC [message #168919] |
Sat, 19 February 2005 18:34  |
Eclipse User |
|
|
|
Originally posted by: usenet.jevopi.de
Hi all,
I'm examining some frameworks and discussing some special
implementations of design patterns. I'm particularly interested in
interaction patterns like MVC (model view controller) and PAC
(presentation abstraction control). After examining lifecycle and event
handling of editparts, figures and the model objects, I'm wondering
whether GEF is implementing MVC or PAC.
Since I'm new to PAC, I'm not sure.. I only have some indications:
Architecture: Compared to other MVC implementations, where the view and
controller parts are often combined, GEF separates these components
very strictly. Comparing the GEF and Eclipse components to PAC agents,
it looks like the Eclipse core, i.e. the Eclipse application, can be
interpreted as a Top-level agent, the GEF EditViewPart/EditDomain as a
Intermediate-level agent and the "small" EditPart/Figure parts as
Bottom agents. This hierarchy can also be found in the organization of
the EditParts. On MVC, views are containers containing other views. GEF
creates the hierarchy by the EditParts as well - a child figure of
another figure is useless (for use interactions) if there's no editpart
for it. I'm not sure how to rate this... are the editparts creating the
hierarchy, or the figures.. or the model?
Lifecycle: On MVC, the view part is creating the controller. On PAC,
the agent opens a view, IMHO that is the control creates the view. This
is how GEF is working (EditPart:getFigure).
Observer-Pattern: On MVC, the view can observe the model. The
controller only apply changes, but the view is expected to retrieve
data from the view itsself. This is possible with GEF, too. But I've
got the feeling it's more recommended that the controller "copies" the
data from the model to the view, thus view and model are independent
from each other. This structure is shown is the PAC structure- and
sequence diagrams too (see Buschmann, Pattern oriented architecture).
I tend to say that GEF is implementing the PAC pattern. What would you say?
Jens
|
|
|
| Re: MVC or PAC [message #168986 is a reply to message #168919] |
Mon, 21 February 2005 07:24  |
 Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C517BC.6BB80640
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
AFAIK, PAC is presentation-application-control, not =
presentation-abstraction-control. And therein lies a hint. My =
understanding is that MVC and PAC are not different per se, rather MVC =
evolved into PAC (which further evolved into PAC-AMODEUS -- Assimilating =
MOdels of DEsigners, Users and Systems). If I absolutely had to choose =
between these two options, I would agree with your assessment that GEF =
is closer to PAC than it is to MVC. However, I think GEF doesn't =
exactly fit either one of those architectures and is really a result of =
further evolution and inclusion of other architectures. Secondly, I =
think the term MVC is used commonly today to refer to a bunch of =
variants (including PAC and its variants) of the original paradigm. =
From what you mention in your post, it seems your notions of MVC and PAC =
also vary from the original ones (which, I believe, would be quite =
dysfunctional if employed without modification nowadays). While I am =
familiar with the historical models, I've never studied any variants in =
enough detail to be able to comment about PAC agents, life cycle, bridge =
b/w model and view etc. I've always been under the impression that =
those are subject to the requirements of your application.
As far as GEF is concerned, the official answer to your question is =
MVC*.
* where MVC refers to the architecture employed by GEF, and means =
exactly what we want it to mean -- no more, no less. ;-)
"Jens v. P." <usenet@jevopi.de> wrote in message =
news:cv80uj$ani$1@www.eclipse.org...
> Hi all,
>=20
> I'm examining some frameworks and discussing some special=20
> implementations of design patterns. I'm particularly interested in=20
> interaction patterns like MVC (model view controller) and PAC=20
> (presentation abstraction control). After examining lifecycle and =
event=20
> handling of editparts, figures and the model objects, I'm wondering=20
> whether GEF is implementing MVC or PAC.
>=20
> Since I'm new to PAC, I'm not sure.. I only have some indications:
>=20
> Architecture: Compared to other MVC implementations, where the view =
and=20
> controller parts are often combined, GEF separates these components=20
> very strictly. Comparing the GEF and Eclipse components to PAC agents, =
> it looks like the Eclipse core, i.e. the Eclipse application, can be=20
> interpreted as a Top-level agent, the GEF EditViewPart/EditDomain as a =
> Intermediate-level agent and the "small" EditPart/Figure parts as=20
> Bottom agents. This hierarchy can also be found in the organization of =
> the EditParts. On MVC, views are containers containing other views. =
GEF=20
> creates the hierarchy by the EditParts as well - a child figure of=20
> another figure is useless (for use interactions) if there's no =
editpart=20
> for it. I'm not sure how to rate this... are the editparts creating =
the=20
> hierarchy, or the figures.. or the model?
>=20
> Lifecycle: On MVC, the view part is creating the controller. On PAC,=20
> the agent opens a view, IMHO that is the control creates the view. =
This=20
> is how GEF is working (EditPart:getFigure).
>=20
> Observer-Pattern: On MVC, the view can observe the model. The=20
> controller only apply changes, but the view is expected to retrieve=20
> data from the view itsself. This is possible with GEF, too. But I've=20
> got the feeling it's more recommended that the controller "copies" the =
> data from the model to the view, thus view and model are independent=20
> from each other. This structure is shown is the PAC structure- and=20
> sequence diagrams too (see Buschmann, Pattern oriented architecture).
>=20
> I tend to say that GEF is implementing the PAC pattern. What would you =
say?
>=20
> Jens =20
>
------=_NextPart_000_000A_01C517BC.6BB80640
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>AFAIK, PAC is =
presentation-application-control, not=20
presentation-abstraction-control. And therein lies a hint. =
My=20
understanding is that MVC and PAC are not different per se, rather MVC =
evolved=20
into PAC (which further evolved into PAC-AMODEUS -- Assimilating MOdels =
of=20
DEsigners, Users and Systems). If I absolutely had to choose =
between these=20
two options, I would agree with your assessment that GEF is closer to =
PAC than=20
it is to MVC. However, I think GEF doesn't exactly fit either one =
of those=20
architectures and is really a result of further evolution and inclusion =
of other=20
architectures. Secondly, I think the term MVC is used commonly =
today to=20
refer to a bunch of variants (including PAC and its variants) of the =
original=20
paradigm. From what you mention in your post, it seems your =
notions of MVC=20
and PAC also vary from the original ones (which, I believe, would be =
quite=20
dysfunctional if employed without modification nowadays). While I =
am=20
familiar with the historical models, I've never studied any variants in =
enough=20
detail to be able to comment about PAC agents, life cycle, bridge b/w =
model and=20
view etc. I've always been under the impression that =
those are=20
subject to the requirements of your application.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As far as GEF is concerned, the =
official answer to=20
your question is MVC*.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D1>* where MVC refers to the architecture =
employed by=20
GEF, and means exactly what we want it to mean -- no more, no =
less. =20
;-)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Jens v. P." <</FONT><A=20
href=3D"mailto:usenet@jevopi.de"><FONT face=3DArial=20
size=3D2>usenet@jevopi.de</FONT></A><FONT face=3DArial size=3D2>> =
wrote in message=20
</FONT><A href=3D"news:cv80uj$ani$1@www.eclipse.org"><FONT face=3DArial=20
size=3D2>news:cv80uj$ani$1@www.eclipse.org</FONT></A><FONT face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> Hi =
all,<BR>> <BR>> I'm=20
examining some frameworks and discussing some special <BR>> =
implementations=20
of design patterns. I'm particularly interested in <BR>> interaction =
patterns=20
like MVC (model view controller) and PAC <BR>> (presentation =
abstraction=20
control). After examining lifecycle and event <BR>> handling of =
editparts,=20
figures and the model objects, I'm wondering <BR>> whether GEF is=20
implementing MVC or PAC.<BR>> <BR>> Since I'm new to PAC, I'm not =
sure.. I=20
only have some indications:<BR>> <BR>> Architecture: Compared to =
other MVC=20
implementations, where the view and <BR>> controller parts are often=20
combined, GEF separates these components <BR>> very strictly. =
Comparing the=20
GEF and Eclipse components to PAC agents, <BR>> it looks like the =
Eclipse=20
core, i.e. the Eclipse application, can be <BR>> interpreted as a =
Top-level=20
agent, the GEF EditViewPart/EditDomain as a <BR>> Intermediate-level =
agent=20
and the "small" EditPart/Figure parts as <BR>> Bottom agents. This =
hierarchy=20
can also be found in the organization of <BR>> the EditParts. On MVC, =
views=20
are containers containing other views. GEF <BR>> creates the =
hierarchy by the=20
EditParts as well - a child figure of <BR>> another figure is useless =
(for=20
use interactions) if there's no editpart <BR>> for it. I'm not sure =
how to=20
rate this... are the editparts creating the <BR>> hierarchy, or the =
figures..=20
or the model?<BR>> <BR>> Lifecycle: On MVC, the view part is =
creating the=20
controller. On PAC, <BR>> the agent opens a view, IMHO that is the =
control=20
creates the view. This <BR>> is how GEF is working=20
(EditPart:getFigure).<BR>> <BR>> Observer-Pattern: On MVC, the =
view can=20
observe the model. The <BR>> controller only apply changes, but the =
view is=20
expected to retrieve <BR>> data from the view itsself. This is =
possible with=20
GEF, too. But I've <BR>> got the feeling it's more recommended that =
the=20
controller "copies" the <BR>> data from the model to the view, thus =
view and=20
model are independent <BR>> from each other. This structure is shown =
is the=20
PAC structure- and <BR>> sequence diagrams too (see Buschmann, =
Pattern=20
oriented architecture).<BR>> <BR>> I tend to say that GEF is =
implementing=20
the PAC pattern. What would you say?<BR>> <BR>> =
Jens =20
<BR>> </FONT></BODY></HTML>
------=_NextPart_000_000A_01C517BC.6BB80640--
|
|
|
| Re: MVC or PAC [message #169022 is a reply to message #168986] |
Mon, 21 February 2005 11:18 |
| Eclipse User |
|
|
|
Originally posted by: usenet.jevopi.de
Thank your for your answer. It helped me very much, since it confirmed
some of my thoughts.
> AFAIK, PAC is presentation-application-control, not =
> presentation-abstraction-control.
My reference is
[POSA]
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michaek
Stal (1996):
Pattern-Oriented Software Architecture: A System of Patterns. John
Wiley & Sons.
Hmm.. all references I've found (using google ;) ) are talking about
presentation-abstraction-control.
> And therein lies a hint. My =
> understanding is that MVC and PAC are not different per se, rather MVC =
> evolved into PAC (which further evolved into PAC-AMODEUS -- Assimilating =
> MOdels of DEsigners, Users and Systems).
PAC-AMODEUS - cool acronym ;)
In the book mentioned above, MVC and PAC are different.
> If I absolutely had to choose =
> between these two options, I would agree with your assessment that GEF =
> is closer to PAC than it is to MVC.
That makes me smile :)
> However, I think GEF doesn't =
> exactly fit either one of those architectures and is really a result of =
> further evolution and inclusion of other architectures.
Of course.
> Secondly, I =
> think the term MVC is used commonly today to refer to a bunch of =
> variants (including PAC and its variants) of the original paradigm. =
Yes - IMHO that's a big problem. MVC is becoming the "do the right
thing"-pattern of user interfaces.
> From what you mention in your post, it seems your notions of MVC and PAC =
> also vary from the original ones (which, I believe, would be quite =
> dysfunctional if employed without modification nowadays).
Which are the original ones?
I used the following articles / books:
PAC:
[POSA] (see above)
MVC:
GoF - Design patterns
and
Glenn Krasner, Stephen Pope (1988): A Cookbook for Using the
Model-View-Controller
User Interface Paradigm in Smalltalk-80. Journal of Object-Oriented
Programming, Aug./Sept. 1988, pp 26-49
> As far as GEF is concerned, the official answer to your question is =
> MVC*.
"Official" - hard to argue about that ;)
Jens
|
|
|
| Re: MVC or PAC [message #169069 is a reply to message #168986] |
Mon, 21 February 2005 15:14 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
I'm not so knowledgeable on this topic, but on the surface it would
appear that MVC applies nicely to GEF.
Model - your model class
View - Figure
Controller - Editpart
The center of GEF is the editpart, the Editpart which is the controller
is further broken down into strategies. what element of the GEF
architecture makes it appear more PAC than MVC?
Thanks for the info,
CL
Pratik Shah wrote:
> AFAIK, PAC is presentation-application-control, not
> presentation-abstraction-control. And therein lies a hint. My
> understanding is that MVC and PAC are not different per se, rather MVC
> evolved into PAC (which further evolved into PAC-AMODEUS -- Assimilating
> MOdels of DEsigners, Users and Systems). If I absolutely had to choose
> between these two options, I would agree with your assessment that GEF
> is closer to PAC than it is to MVC. However, I think GEF doesn't
> exactly fit either one of those architectures and is really a result of
> further evolution and inclusion of other architectures. Secondly, I
> think the term MVC is used commonly today to refer to a bunch of
> variants (including PAC and its variants) of the original paradigm.
> From what you mention in your post, it seems your notions of MVC and
> PAC also vary from the original ones (which, I believe, would be quite
> dysfunctional if employed without modification nowadays). While I am
> familiar with the historical models, I've never studied any variants in
> enough detail to be able to comment about PAC agents, life cycle, bridge
> b/w model and view etc. I've always been under the impression that
> those are subject to the requirements of your application.
>
> As far as GEF is concerned, the official answer to your question is MVC*.
>
> * where MVC refers to the architecture employed by GEF, and means
> exactly what we want it to mean -- no more, no less. ;-)
>
> "Jens v. P." <usenet@jevopi.de <mailto:usenet@jevopi.de>> wrote in
> message news:cv80uj$ani$1@www.eclipse.org...
> > Hi all,
> >
> > I'm examining some frameworks and discussing some special
> > implementations of design patterns. I'm particularly interested in
> > interaction patterns like MVC (model view controller) and PAC
> > (presentation abstraction control). After examining lifecycle and event
> > handling of editparts, figures and the model objects, I'm wondering
> > whether GEF is implementing MVC or PAC.
> >
> > Since I'm new to PAC, I'm not sure.. I only have some indications:
> >
> > Architecture: Compared to other MVC implementations, where the view and
> > controller parts are often combined, GEF separates these components
> > very strictly. Comparing the GEF and Eclipse components to PAC agents,
> > it looks like the Eclipse core, i.e. the Eclipse application, can be
> > interpreted as a Top-level agent, the GEF EditViewPart/EditDomain as a
> > Intermediate-level agent and the "small" EditPart/Figure parts as
> > Bottom agents. This hierarchy can also be found in the organization of
> > the EditParts. On MVC, views are containers containing other views. GEF
> > creates the hierarchy by the EditParts as well - a child figure of
> > another figure is useless (for use interactions) if there's no editpart
> > for it. I'm not sure how to rate this... are the editparts creating the
> > hierarchy, or the figures.. or the model?
> >
> > Lifecycle: On MVC, the view part is creating the controller. On PAC,
> > the agent opens a view, IMHO that is the control creates the view. This
> > is how GEF is working (EditPart:getFigure).
> >
> > Observer-Pattern: On MVC, the view can observe the model. The
> > controller only apply changes, but the view is expected to retrieve
> > data from the view itsself. This is possible with GEF, too. But I've
> > got the feeling it's more recommended that the controller "copies" the
> > data from the model to the view, thus view and model are independent
> > from each other. This structure is shown is the PAC structure- and
> > sequence diagrams too (see Buschmann, Pattern oriented architecture).
> >
> > I tend to say that GEF is implementing the PAC pattern. What would
> you say?
> >
> > Jens
> >
|
|
|
Goto Forum:
Current Time: Thu Apr 25 10:00:23 GMT 2024
Powered by FUDForum. Page generated in 0.02901 seconds |
] 
Search
Help
Register
Login
Home
