Comments on: Flash Layout Engine in Reflex http://xtyler.com/code/296 a developer's blog. Tue, 19 Apr 2011 14:30:37 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Scott http://xtyler.com/code/296/comment-page-1#comment-11998 Scott Thu, 24 Jun 2010 09:07:36 +0000 http://www.xtyler.com/?p=296#comment-11998 The BoxGraphic isn't included in the demo folder by the looks of things. Cheers, Scott The BoxGraphic isn’t included in the demo folder by the looks of things.

Cheers,

Scott

]]> By: Francis Varga http://xtyler.com/code/296/comment-page-1#comment-11985 Francis Varga Fri, 23 Apr 2010 11:02:09 +0000 http://www.xtyler.com/?p=296#comment-11985 Awesom framework! :) Do you have a FLA wherea all components are inluded? :) That's very nice also, save many times :)... Awesom framework! :)

Do you have a FLA wherea all components are inluded? :)

That’s very nice also, save many times :) …

]]> By: xtyler http://xtyler.com/code/296/comment-page-1#comment-11984 xtyler Tue, 20 Apr 2010 15:48:31 +0000 http://www.xtyler.com/?p=296#comment-11984 Scott, the Reflex initial website has finally been released and should have some additional information there. http://www.reflex.io Scott, the Reflex initial website has finally been released and should have some additional information there. http://www.reflex.io

]]> By: Scott http://xtyler.com/code/296/comment-page-1#comment-11983 Scott Mon, 12 Apr 2010 10:13:39 +0000 http://www.xtyler.com/?p=296#comment-11983 Sorry if this is obvious but where is the reflex.swc? Sorry if this is obvious but where is the reflex.swc?

]]> By: Glidias http://xtyler.com/code/296/comment-page-1#comment-11977 Glidias Thu, 01 Apr 2010 16:39:38 +0000 http://www.xtyler.com/?p=296#comment-11977 I know Blocks can be used standalone. BlockBehaviour was just a standalone adaptor wrapper because my API uses a specific interface-method activate(target:*):void & destroy():void over a target object, which is pretty archaic/boiler-plate heavy on hindsight (What was i thinking?). I'd definitely have to refactor that to using a pure "target" setter as the standard (where setting target to 'null disposes off the block/behaviour's listeners), and therefore eliminate the interface dependencies and allow for cross-platform ease. In fact, the benefit of not using interfaces at all to set targets for behaviours is even better because some behaviour targets may not necessarily be InteractiveObjects. Without an interface, the coder is free to create ANY class with set target(val:MyOwnRequiredType), without resorting to casting. It's simply assumed there's a 'target' setter for such classes.. It would be cool to allow Blocks the option to also bind their width and height properties to other properties of the target component, if required (since not all DisplayObjects' width/height values reflect the measured width/height settings used for layouts). I know Blocks can be used standalone. BlockBehaviour was just a standalone adaptor wrapper because my API uses a specific interface-method activate(target:*):void & destroy():void over a target object, which is pretty archaic/boiler-plate heavy on hindsight (What was i thinking?). I’d definitely have to refactor that to using a pure “target” setter as the standard (where setting target to ‘null disposes off the block/behaviour’s listeners), and therefore eliminate the interface dependencies and allow for cross-platform ease. In fact, the benefit of not using interfaces at all to set targets for behaviours is even better because some behaviour targets may not necessarily be InteractiveObjects. Without an interface, the coder is free to create ANY class with set target(val:MyOwnRequiredType), without resorting to casting. It’s simply assumed there’s a ‘target’ setter for such classes..

It would be cool to allow Blocks the option to also bind their width and height properties to other properties of the target component, if required (since not all DisplayObjects’ width/height values reflect the measured width/height settings used for layouts).

]]> By: xtyler http://xtyler.com/code/296/comment-page-1#comment-11973 xtyler Mon, 29 Mar 2010 12:31:37 +0000 http://www.xtyler.com/?p=296#comment-11973 I'm glad you were able to get in and use this! My friend <a href="http://roboncode.com" rel="nofollow">Rob Taylor</a> has already developed a suite of layout algorithms for his own project and doesn't use anything else from the framework successfully. It's a good test of the separation in Reflex. The Block class is already a reusable piece that will target any DisplayObject, you won't need to do any extra work to create a "BlockBehavior". Behaviors are specifically <em>interactive</em> elements for components, while Layouts, Skins etc are other types of reusable systems. I’m glad you were able to get in and use this! My friend Rob Taylor has already developed a suite of layout algorithms for his own project and doesn’t use anything else from the framework successfully. It’s a good test of the separation in Reflex.

The Block class is already a reusable piece that will target any DisplayObject, you won’t need to do any extra work to create a “BlockBehavior”. Behaviors are specifically interactive elements for components, while Layouts, Skins etc are other types of reusable systems.

]]> By: Glidias http://xtyler.com/code/296/comment-page-1#comment-11971 Glidias Sun, 28 Mar 2010 13:30:01 +0000 http://www.xtyler.com/?p=296#comment-11971 I've peeked into the code and with the exception of ScrollBlock in the reflex.layout package, the rest of the layout classes do not require any Binding dependencies whatsoever, which makes this quite easy to extract out and integrate into a reusable BlockBehaviour class that can be applied to any display object (or IBoxModel-based) display for my own collection . After all, I need some basic dock and center fill liquid layout functionality, and this package, though it seems not fully incomplete in some parts (a bit of to-dos), can help in that area. I’ve peeked into the code and with the exception of ScrollBlock in the reflex.layout package, the rest of the layout classes do not require any Binding dependencies whatsoever, which makes this quite easy to extract out and integrate into a reusable BlockBehaviour class that can be applied to any display object (or IBoxModel-based) display for my own collection . After all, I need some basic dock and center fill liquid layout functionality, and this package, though it seems not fully incomplete in some parts (a bit of to-dos), can help in that area.

]]> By: Jonas Nyström http://xtyler.com/code/296/comment-page-1#comment-11923 Jonas Nyström Wed, 03 Mar 2010 15:16:02 +0000 http://www.xtyler.com/?p=296#comment-11923 Aargh, would really love to change some snowy northern swedish days to sunny and relaxed californian ones..! Good luck with your 360 Flex presentation! Looking forward to follow (and maybe somehow contribute) to the Reflex progress! Aargh, would really love to change some snowy northern swedish days to sunny and relaxed californian ones..! Good luck with your 360 Flex presentation! Looking forward to follow (and maybe somehow contribute) to the Reflex progress!

]]> By: Sylvain Lecoy http://xtyler.com/code/296/comment-page-1#comment-11919 Sylvain Lecoy Fri, 26 Feb 2010 23:11:12 +0000 http://www.xtyler.com/?p=296#comment-11919 Did you notice that with Flex Builder 4 when we Eporting Release Build (optimized SWF or Adobe AIR File) the demo doesn't work anymore ? Did you notice that with Flex Builder 4 when we Eporting Release Build (optimized SWF or Adobe AIR File) the demo doesn’t work anymore ?

]]> By: James Ward http://xtyler.com/code/296/comment-page-1#comment-11898 James Ward Wed, 17 Feb 2010 15:29:20 +0000 http://www.xtyler.com/?p=296#comment-11898 Wow! That demo loaded so fast that I initially thought it was a screenshot of the demo! Nice work! Wow! That demo loaded so fast that I initially thought it was a screenshot of the demo! Nice work!

]]>