Filed under: actionScript, client side, components, flex, jwo_lib, projects | Tags: actionScript, components, development, flex, jwolib, mxml
For those of you who use the Pod component I fixed the annoying issue of where title bar children’s visibile properties being set in MXML did not stick. Anyway revision 122 addresses this issue.
Filed under: actionScript, client side, components, development, flash, flex, jwo_lib, mxml
A user of the lib brought to my attention a major flaw in my default styling setup. This new release address the default styling as well as a few things regarding the TileCanvas’s itemRenderer (IFactory) generator class (now can use UIComponent, should implement IDataRenderer for best use).
jwolib 2008.12.15 (includes src, asdocs & SWC) – link
Since most people instantiate container type classes via MXML rather than in AS3, it made sense to be able to add title bar components to Pod via MXML rather than the tedious addTitleBarComponent method.
Now if you want to add title bar components to a Pod instance, you can do so declaratively. Check out titleBarChildren.
You can view an implementation of this here – link
Filed under: actionScript, components, development, flex, jwo_lib
I finally got around to using Flex Builder 3 for my personal projects since the project I am working for migrated to it awhile back. Call me a late adopter.
Generally when you think of pagination, you might think immediately about returned search results from google. You know, the little arrows down at the bottom indicating the previous and next pages with links to the pages in between them. Now to me, a RIA will hopefully find a better means of implementing paginated data, whether that be via internal scrollbars or collapsible/expandable* content. But sometimes a design or use-case doesn’t allow for it. A good implementation of this can be found on the Kuler app.
I really like their implementation but since that design and custom functionality might not fit with a future design/use-case I wanted to find a reusable solution. So how does one go about formalizing that sort of functionality?
The first step is to disconnect the functionality from the design implementation. An interface is a good candidate for this as it ensures that regardless of the UI, you can expect a certain feature set. Enter IPaginatedItemsControl. I won’t go into detail about it as you can read the docs but suffice it to say that this is the starting point for building any paginated items control. The next step is actually building out some of the functionality and making a container to host the custom controls. Check out PaginatedItemsControlBase. Its basically an empty box with most of the needed functionality. All it lacks are the controls in order to browse the paginated content. Some might ask why I even bothered with any interface. This was intended to allow a developer to customize the inner workings of the implementor if they found the PaginatedItemsControlBase too restrictive.
Anyway, I have a new build on the project home as well as updated documentation on all the jwoLib components. Certainly sound off as I appreciate the feedback and criticism.
* Being somewhat of a English/grammar guy, I really don’t understand the rules for adjective modifiers. Logic would suggest that since collapse and expand are antonyms that their adjective modifier would be the same: verb + modifier. This is not the case though. It seems there is no rhyme or reason to how these modifiers are selected. Anyone?
Filed under: actionScript, components, development, flex, jwo_lib
[UPDATE]
Thanks to Holmes (comments below) I had just enough info to use the proper search string. It is indeed called “mark occurrences”. And for those having a hard time finding where in the IDE it resides, here is a screen shot for you:
Since a few folks who have been trying to use jwoLib in Flex 3 projects have reported some funky bugs with the component set, I figured I would try to get in there and work them out.
I remember the last time I got on FB3 I was highly annoyed to find that every time you type something, it tries to highlight the code for you to show you other instances within the document. I also remember not being the only one annoyed as someone had posted how one might disable this pain in the rear. I just can’t seem to find the post or other relevant info on how to turn it off. Nor can I seem to find the option in the preferences. Can someone please refresh my memory?
Thanks,
J
Filed under: actionScript, components, development, flash, flex, jwo_lib
Preface
While working on my current project, a coworker and I were discussing naming conventions. So I thought I would throw this out there for your intellectual consumption and maybe spit back some enlightenment, if you will please. This will be broken down into two sections/questions, the first dealing with instance names and the latter dealing with package naming conventions. I do realize this is a matter of personal preference however I would like to gather some input on what my fellow developers use and the pros/cons of those conventions.
Instance Naming Conventions
Coming from an old flash background I was of the school of thought that instance names would use a suffix-convention whereas let’s say a movieClip instance with a profile picture would be called something like “profilePicture_mc”, or a textField with info about a first name would be called “firstName_txt” or “firstName_tf”. That sounds great so far. I bet many are wondering why the hell this would even become a point of issue for me. The simple answer is I have OCD about things like this. The fact that half my projects might use one convention while the other half uses another would keep me awake at night in a cold sweat. Yes, I am that screwed up. But I digress…
My coworker suggested that since we are rebuilding much of our project from the ground up that we may try to take real advantage of the code hinting mechanisms in Flex Builder by switching up our naming convention. I, being a contractor/consultant, would generally capitulate on matters such as this, with the wisdom lying in that I may not be around in 3 months, he will and he should have the code as agreeable to him as much as possible.
His suggested naming convention entails a simple switch of prepending the class type before the context-specific name. So rather than “profile_img”, you would have “img_profile”. Though not semantically logical as the first system, it does leverage Flex’s code hinting in that all images would be grouped together when selecting the correct instance.
Anyway I wanted to toss that to the elder hounds of development for discussion. It’s not as important to me as the next topic.
Package Naming Conventions
Here I stand at a crossroads in the further development of class libraries and applications. Generally my packaged libraries have the following generally accepted naming convention: com.jwopitz. followed by the typical model or controller or view sub-packages. The issue I have with this is I do own www.jwopitz.com’s domain name but really have no intention of using it for anything. Also for the level of detail I take in separating my packages out, this convention doesn’t lend itself to shorter full-class-pathnames.
So rather than using the subdomain.domain.top-lvl-domain package naming conventions I have started to mull over the idea of doing what adobe does which is basically technology.sub-package or whatever you want to call it. I’d like to have something more like: jwo.libName.sub-package or jwopitz.libName.sub-package much like flash.events or mx.core. Here is an example of what I am dealing with currently
I started a lib called jwo_mediaCoreLib that has various interfaces and manager type classes. Right now it has a class path appearing something like: com.jwopitz.managers.IPlaylistManagerClient. This is great if isolated for use inside the swc. But damned if it seems clean to use in some big application that has its own com.jwopitz.managers package. I just don’t like how it meshes together.
Conclusion
Well after rambling on sometime about my obsessions and finally realizing I have WAY TOO MUCH TIME ON MY HANDS, I leave the topic of debate to your comments. I would love some feedback on this. Even if it is to berate me for being OC.
Thanks for listening to my thoughts
Filed under: actionScript, components, development, flex, jwo_lib
I have been working on a personal project for sometime now. It makes heavy use of forms and renderer type class. This means loads of mx:TextInput. The issue was that I wanted the effect of inline editing on a form that, at first glance, looks like any pre-filled data will just appear as labels (or in this case a TextInputs minus their borders).
One approach was to simply use mx:states and swap out labels for textInputs and visa versa when needed. That would probably entail either some intense if/else and switch statements or just doing a massive form state swap when one of the controls is activated. I don’t like this because a) it deals with states which IMHO kinda suck and are finicky and b) seems very inefficient.
The other approach (which I opted for) was to have the actual control switch its state manually. In this case not states as in mx:states but rather it would handle its own display logic based on the user interaction. Enter the new com.jwopitz.controls.TextInput. When you are not editing it looks like a simple label with a prompt and when you want to edit it, WHALLLA, just click it and it appears to be the TextInput it really is.
I think this makes the component itself more inline with what a RIA is. Forms by nature are not really all that exciting and RIA-ish. I mean really, how much more fun can entering data be? But this very simple addition to the TextInput’s feature set might help make a boring form into a ….. well … less….. boring form. 
Keep in mind, even though I have done quite a bit of use testing with this, there may be a few undiscovered bugs. Hey its a beta version right? If any major issues come up, shoot me an email.
Anywhoo… I have updated jwo_lib and the example file (link above). I will post updates to the docs here shortly.
Yeah yeah yeah. I know you are probably saying ‘Big Deal!’. Well it was long over due. Here is the links for you folks:
http://jwopitz-lib.googlecode.com/svn/examples/example
But there is that problem of it not properly rendering the html files in Firefox. Fine in IE but FF craps out. You can read a forum post about the issue…
Thanks,
Justin
Yes finally I have added ASDOCs to jwo_lib. I am sorry it has taken this long. It is still a work in progress too so if you see some things that just don’t jive, post a comment or give it a few days and it should be fine. I am also taking this coming week to post the sample applications in order to show off the components in jwo_lib.
One thing to note is that for some reason Firefox doesn’t render the frames for the docs. IE seems to work fine.
