[gme-users] Constraint problem

[Jeff Parsons]

If the new behavior you proposed for the Constraint Manager is not to be
hard-wired, then my
last question is indeed irrelevant. Thanks for clearing that up.


  _____  

	From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Larry
H.
	Sent: Thursday, March 02, 2006 12:42 PM
	To: gme-users
	Subject: RE: [gme-users] Constraint problem
	
	
	Both of these are legitimate reasons to use the feature I
propose with diligence, but not for disallowing it.  Indeed, from the
point of view of my intended use they are both irrelevant.  The amended
feature proposal does not require any changes to how folks are using
GME's constraint manager today.  It just opens up some additional
possibilities.  What's wrong with that?

		-----Original Message-----
		From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Matthew
J. Emerson
		Sent: Thursday, March 02, 2006 12:22 PM
		To: gme-users
		Subject: RE: [gme-users] Constraint problem
		
		

		Similarly, what about the case where you build a large
model, then go back and edit the paradigm to include a constraint like
the one you describe after-the-fact. The constraint could never be
evaluated for the existing cases where it might be violated.

		 

		--Matt

		 

		
  _____  


		From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Jeff
Parsons
		Sent: Thursday, March 02, 2006 12:20 PM
		To: gme-users
		Subject: RE: [gme-users] Constraint problem

		 

		If incorrect XML is generated and imported into GME, and
the part of the model corresponding to 

		the incorrect XML is not modified by the modeler, what
event would trigger the check?

			 

			
  _____  


			From: gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Larry
H.
			Sent: Thursday, March 02, 2006 12:15 PM
			To: gme-users
			Subject: RE: [gme-users] Constraint problem

			Thanks Jeff, this helps clarify my proposal.

			 

			I propose instead the ability to say that a
constraint should be checked exclusively on the associated events.  

			 

			I think that this would put things nicely into
the hands of the meta-modeler.

				-----Original Message-----
				From:
gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Jeff
Parsons
				Sent: Thursday, March 02, 2006 10:56 AM
				To: gme-users
				Subject: RE: [gme-users] Constraint
problem

				What about the case where GME is used
with other tools, for example one that generates

				XML for GME to import. If this tool had
a bug and generated something that violated the

				constraint in question, wouldn't "Check
All" be the only way to catch it?

				 

				
  _____  


				From:
gme-users-bounces at list.isis.vanderbilt.edu
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of Larry
H.
				Sent: Thursday, March 02, 2006 10:32 AM
				To: gme-users
				Subject: [gme-users] Constraint problem

				I'm having a problem defining a
constraint that concerns a change in number of children in a container.
My intention is to check this constraint on an event, like
"onlostchild", and to prevent the action by setting the constraint's
Priority=1.  My problem is to find an approach that does not
subsequently trigger a violation when the user chooses the 'Check All'
action of the Constraint Manager.

				 

				It is my current belief that there is no
way to define such a constraint.  The reason is that the focus of this
constraint is "change", whereas the focus of the Constraint Manager, in
general, is "current state".   Constraints concerning "change" typically
involve knowing "state before" and "state after".  Have I failed to
consider something?

				 

				One thing that occurs to me is that the
Constraint Manager might consider not checking constraints on "Check
All" that are checked on events with Priority=1.  The intuition is that,
since such event-based constraints can only result in aborting the
action, there is simply no reason to check them again on "Check All".
Such a feature would allow the desired constraint to be defined quite
simply with a "false" predicate.

				 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/gme-users/attachments/20060302/f2cb0f28/attachment.htm