[Golist] the possibilities of go

[Moses Gunesch]

I started with a simple multi-prop tween, then created a separate  
parser class with 2 public static methods called BlockParserMG:

public static function go(action:Object): BlockTweenMG {
	// parse, start & return a tween
	var tween:BlockTweenMG = parseAction(action);
	tween.start();
	return tween;
}

public static function sequence(...actions): SequenceCA {
	// parse, start, and return a sequence
}

private static function parseAction(action : Object) : BlockTweenMG {
	// used by both. parse one action object and return a tween.
}


I built SequenceStepCA's during the sequence() loop because that way i  
could support custom-advance. I checked for "is Array" for each action  
passed in and would parse each sub-object within it to support  
parallel. That's just a few lines of code to do both of those things  
then sequence.addStep(step);.

The parser is literally one if() statement for the custom-advance and  
one if() to see if the property being parsed is a tween property  
(tween.hasOwnProperty(prop)) or should else just be added as an  
animation property.

That's it... simple!

And ... works!

-m



On Mar 5, 2008, at 7:42 PM, Brett Coffin wrote:

> Hi everyone,
>
> Moses, i love the concept of Go i thing it will "go" all the way !!!
>
> I understand the concept of the parser in regards to xml but i don't  
> have a clear idea of what would be a parser for go, could you extend  
> on it... the way i am think of it  is:
>
> you created a syntax like the fuse for example and the parser is  
> receiving it and then would "dispatch" the task to tween particular  
> parameters to the respective tweening class... is that correct ?  
> Could you make your  parser  available ?
>
>
>
>
>
> On Thu, Mar 6, 2008 at 10:18 AM, Moses Gunesch <moses at goasap.org>  
> wrote:
> That's true and so far it hasn't really come in handy at all. I had
> put it in there so it would be easy to pass target or prop info but
> it's also easy to just add those params since it's all open code. You
> are right that I should probably remove that since it simply
> encourages bad practice, I just didn't want it to be terribly
> restrictive either... will revisit.
>
> - m
>
>
> On Mar 5, 2008, at 12:03 PM, Jon Williams wrote:
>
> > if the 'extra' prop is such a rotten approach, then i suggest
> > removing it from GoEvent (unless you can tell me how that's
> > different) ; ) Afterall, you should just subclass GoEvent...
> > :j
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080305/da1d50db/attachment.html