the singularity of being and nothingness
Archive for November, 2012
Virtual Directory-Driven ExtJS 4 Development – The Finale
Nov 24th
If you’ve been following along the last few posts, you’ve seen how it’s relatively simple to set up your local development environment to leverage global library assets to create ExtJS 4 applications. What you’ve probably also noticed is that there are a number of configurations (some one-time, others per-application) that need to be implemented before it will work. While these are not necessarily that big of a deal (especially in light of the benefits you gain), it’s still a lot. Here’s the full list:
- Generate application with Sencha Cmd
- Add virtual directories (ExtJS library, global plugins, and resources)
- Update ext.dir in /app/.sencha/workspace/sencha.cfg
- Add workspace.classpath in /app/.sencha/workspace/sencha.cfg
- Add full host path to /app/resources/theme/{themename}/theme.html
- Update $ext_path in /app/resources/sass/{themename}/config.rb
- Add fixes to /extroot/resources/themes/lib/Utils.rb (one time)
- Update /app/.sencha/app/build.impl.xml to copy theme images to app folder
- Develop application
- Build application and theme
So only 9 per-app steps…not too bad. But wouldn’t it be WAY better if this number could drastically reduced?
WARNING!! WARNING!! WARNING!!
What follows is a total hack. The steps outlined will show you how to modify your Sencha Cmd installation so that the configurations previously outlined will now be the “default”. These changes apply only to ExtJS 4 app creation and compile/build. I didn’t bother with the more advanced commands in Sencha Cmd, nor with anything relating More >
Virtual Directory-Driven ExtJS 4 Development – Part Second
Nov 21st
In my last post, I outlined a method that can be used to develop compilable-ExtJS 4 applications, with minimal configuration, that leverage a common, global location for shared assets and libraries. This approach works fine if you are merely “compiling” the application (e.g., only the JS part). However, if you do the full “build” you’ll quickly run into a number of issues.
The most significant of the issues is that the full build process will attempt to compile the theme for your app via the compass compile command. Since our approach decouples the app from the library, AND because we didn’t exactly deal with the SASS/theme bits whatsoever, the errors just roll and roll when building the app.
Fortunately, the fix is pretty easy. In the following, I’ll outline some necessary pre-requisites you’ll need to get setup before building, and then I’ll suggest a few options for how to do this.
Another Virtual DirectorySince we’re primarily interested in styles–particularly images–we need another virtual directory that will point to the images for our theme.
In httpd.conf, I’ve added the following:
Alias /sencha/testapp/resources/images "/Users/{username}/sencha/extjs/resources/themes/images"
NOTE: If you are developing your own custom theme that will be app-specific, you can skip this step and just put the theme images in More >
Virtual Directory-Driven ExtJS 4 Development
Nov 15th
Over the last several months, I’ve been incredibly lucky to be able to work with ExtJS 4 on a daily basis. And I’m not just talking about dabbling here and there; rather, I mean developing a full-on legit application. It’s been awesome.
As I’ve been building this application, I’ve developed a TON of custom, reusable code. Some of it is app-specific, but a lot of it is application-agnostic. For example, in my ColdFusion settings, all AJAX responses are prepended with “//”. Doesn’t sound like a big deal, but the default ExtJS 4 data readers don’t understand this…so I built a set of custom reader extensions that solve this problem.
So now that the application is more in “maintenance” mode, I’ve been taking an inventory of all the custom, globally-reusable extensions and plugins that I’ve created. And it’s got me wondering about how, exactly, one should (or could) leverage all this reusable goodness in a way that doesn’t require a clunky copy-paste for every project.
WorkspacesWith the release of Sencha Cmd 3.0, you can now leverage the concept of a “workspace” to aid in managing reusable code. I’ve not personally used this yet, but it seems like a really nice solution.
There is one serious More >
ColdFusion ORM – Collection…was not processed by flush()
Nov 14th
This is more for my own memory, but perhaps it will be useful to others 🙂
Let’s say I have the following entities:
User.cfc
component persistent="true" entityname="User" table="User" { property name="UserID" fieldtype="id"; property name="Name"; property name="Age"; property name="Group" fieldtype="many-to-one" cfc="Group" fkcolumn="GroupID"; }
Group.cfc
component persistent="true" entityname="Group" table="Group" { property name="GroupID" fieldtype="id"; property name="Name"; property name="Activities" fieldtype="one-to-many" fkcolumn="GroupID" linktable="Activity" inversejoincolumn="ActivityID"; }
Ok, so let’s also imagine that I’m trying to leverage the postDelete() event to make an audit record of any User deletions that I make:
// function postDelete( entity ) { // get properties from entity that I want to log ... ... }
When I try to do this, I get something like:
collection >> [Group.Activities] was not processed by flush()
I banged my head on this wall for a while, until I finally figured out the issue.
The issue is the “laziness” of the “Group” property on the User entity. Since I have no value specified, it is equivalent to having specified “lazy=true”. Since (I assume) the Group property is not being fully “loaded” during the delete operation, there’s no chance that it’s own “Activities” property is loaded either…hence the error.
Anyway, to fix this, I merely added “lazy=false” to my “Group” property. Once in place, I was able to More >