PDA

View Full Version : Possible to work against a live server?



nirvdrum
28 Oct 2012, 3:46 PM
The old SDK tools have the ability to scan against a running server. Does Sencha Cmd have that feature or will it be getting it?

I'm working in a Rails app using the slim templating engine, CoffeeScript here and there, layouts, and the asset pipeline. So being able to hit a rendered copy would probably be my best bet.

dongryphon
28 Oct 2012, 5:30 PM
What framework are you using? There is some support for the old mode for Sencha Touch applications, but the plan is to retire that support so I wouldn't really recommend using it for more than a transitionary period.

Most of the pieces you describe should have little effect on the JS code you need fpr a build (give or take how you use CoffeeScript)... if you can describe your JS code structure a bit, maybe I can offer some suggestions.

nirvdrum
28 Oct 2012, 6:15 PM
Thanks for replying. I'm currently evaluating ExtJS 4. Ironically, the hardest part about it so far is figuring out how to actually integrate it into my project in production.

My use case is probably atypical. I'm looking to integrate it into an existing 3 year old Rails application. So, its introduction will have to be piecemeal. The immediate goal is to use it as a jQuery UI replacement while gaining some additional nice widgets. So, I don't have anything in way of "pages."

The JS structure is a bit ad hoc. Files are currently broken out into:

app/assets/javascripts/<controller>/<action>.js

Since the asset compiler can combine files for us, we find the one file per action layout maps well to the layout used for page templates and stylesheets without necessarily coming at the cost of performance. Please note that the "app" directory here is the standard Rails app directory, not the ExtJS one. Following this structure, I've been placing the ExtJs code into the action-specific JS files. I should probably restructure some of it out into models & stores, but I'm just getting started. And I wasn't sure how to structure that with factory methods, so for now it's all in one file.

To make things a bit more concrete, I have an "admin" controller with a "users" action. I have a grid pulling in JSON content through an AJAX proxy and rendering to a div on the page. The JS is loaded using Rails's javascript_include_tag helper and this resides in a Rails layout file. All view templating is done via Slim, which has a very HAML-like syntax.

Using the old Sencha tools, I've had luck building a JSB3 file by hitting a live server. This was a bit less than ideal though because the admin stuff should be protected, but I had to make it public in order for the tool to access it. But, that did let me build a single file with all the classes I need.

I haven't been able to get anywhere near as far as that with the Sencha Cmd. My understanding after a reading of the docs is that it does a static analysis of HTML-like files. Since my templates look nothing like HTML, use a different comment structure, and don't actually have script tags (they use the Rails helper), I'm not sure how to use it. Pointing a rendered page seems to make the most sense, but I'm open to other suggestions. My next plan is to render in a server, save the file to disk, and run Sencha Cmd against that. Obviously that'd be very kludgy.

Thanks,
Kevin

dongryphon
28 Oct 2012, 8:07 PM
Hi Kevin -

I see, thanks for explaining things a bit. Sounds like there will be a transition phase for sure.

For starters, given your current structure, you probably don't want to attempt to use the "page" command of the compiler since, as you say, you don't have that form of markup anywhere.

Fear not, though, the compiler can be used more directly to just produce concatenated JS files from JS sources. The guide to look at for getting idea here would be:

http://docs.sencha.com/ext-js/4-1/#!/guide/command_compiler

This will explain the set engine that the compiler provides. The general idea is that the compiler processes all JS files in a set of folders (called the "classpath" after the Java concept). Given that set of files, the compiler provides various set operations that allow you to select exactly the set of files you want to combine and then concat them out.

That is basically how we build the various flavors of the framework which, obviously, does not have a markup file to serve as the top-level aggregation point. :)

There are directives (comments) for dealing with non-Ext JS code. The "//@require" and "//@define" directives can be used in any JS file to help show the compiler the dependency graph.

Feel free to drop further questions in this forum as others will probably find the discussion helpful.

Good luck!

nirvdrum
30 Oct 2012, 4:01 PM
Thanks. I'll give this another shot. I passed over it the last time because my understanding is it processes JavaScript sources. Since we're using CoffeeScript, I'd have to precompile the assets while untwiddling the compression, run the sencha compile command, then reprocess with the asset pipeline. While doable, it's several more hurdles to jump through than I'd have just hitting a live server.

I guess we could make the trade-off to use pure JavaScript for all ExtJS files since this is a new initiative. It just kinda clashes with the otherwise use of CoffeeScript we've adopted. C'est la vie I guess.

--
Kevin