Given the case that you have a basic GUI that must be extensible by plugins not known when the generate run of the main GUI is done. Contributable plugins may consist of some manifest, resources, localization, some code that is executable in the GUI environment and can provide custom widgets.
From what I see in the moment, it could be done by
Let a plugin developer build against the ordinary source, generating a part for the plugin. Then manually register a qx.io.part.Part with the generated parts to the GUI running on the non developer side.
Just load a combined source JS for that plugin, containing the resources and load them manually via eval.
I'd personally prefere the first one, as it already includes everything that might be used by a plugin. But it uses a method that is marked as internal.
Are there any experiences with that? Are there other, more elegant ways to achieve that?
Related
When running:
python generate.py source-all
I get all the libraries in my application. This is all good.
When running the application qooxdoo is loading all classes separatly.
I want to use qooxdoo as an online development tool where only the build should be run in the end. Also when running both the server and client in dev mode it runs slow when loading each class of qooxdoo separately.
Can I instead include http://cdnjs.cloudflare.com/ajax/libs/qooxdoo/4.1/q.min.js or a local copy from the server software library folder and for development only run:
python generate.py source
First I'd like to clarify the terms, because I felt some ambiguity in question's.
Terms
Qooxdoo generator's execution unit is a job, e.g. info job is invoked as ./generator.py info. Jobs that are involved in dependency management (finding how an application class depends on other classes from the application, the framework and 3rd party libraries) produce a target. Target may include original classes as-is (by full path), build parts (set of concatenated classes, which may be optimised, plus some meta data and data optionally), or mix of the two. Target is loaded by a web browser via loader.
Source target
Source target jobs are means of dependency management for development (writing code). There are three of such.
source
With the source job all the classes of the application are in their original source form, and their files are directly loaded from their original paths on the file system.
The target includes only actual dependency from the application, the framework and libraries. All classes loaded as-is (hundreds of requests). You may have loading issues even loading it from file:// in some browsers (e.g. in test runner that waits for AUT to load not long enough).
source-all
source-all will include all known classes, be they part of your application, the qooxdoo framework, or any other qooxdoo library or contribution you might be using.
The target includes all existsing classes from the application, the framework and declared libraries. All classes loaded as-is (hundreds of requests, more than for source job). More loading issues than with source job.
source-hybrid (which is default default-job)
The source-hybrid job concatenates the contents of the classes that make up the application into a few files parts, only leaving your own application classes separate. Having the other class files (framework, libraries, contribs) chunked together you get the loading speed of nearly the build version, while at the same time retaining the accessibility of your own application files for debugging.
The target includes only actual dependency from the application, the framework and libraries. All non-application classes are concatenated into parts (dozen or two). Application classes loaded as-is, the rest is loaded from parts. Gives best loading performance.
Build target
There's only one build target job, build. However depending on configuration it can produce a single-file build or partial (multi-file, usually several files) build. Unlike source targets, build target's files are optimised (minified) and intended for production deployment.
Online development
There's example application for online development, playground (application/playground in SDK). Let's look at relevant jobs from its config.json.
"playground-compile" :
{
"extend" : [ "libraries" ],
//...
"include" :
[
"${APPLICATION}.*",
"qx.*"
],
"exclude" :
[
"qx.test.*",
"qx.dev.unit.*",
//..
],
//...
},
"build-script" :
{
"extend" : [ "playground-compile" ],
//...
},
"source" :
{
"extend" : [ "playground-compile" ],
//...
}
As you can see above, for both targets all qooxdoo classes (except tests and development classes) are included so you can use them in playground snippets. Generally it is your case. The rest depends on sort of the online development you have and your requirements to it. You may base it on source-hybrid (easier to debug) or on build target (faster to load). You may mix up some custom configuration, basing it on playground's config.
One important thing that needs to be noted is that if you plan to have significantly more complex code than it is the case for playground snippets, implemented in number of classes that depend on each other, you will need to handle dependency management yourself (i.e. load classes in proper order). If your "online" code deals with a subset of the framework, working with tabular data for instance, it makes sense to include only the subset (e.g. qx.ui.table.* instead of qx.*). For you information, playground's single-file build target is 2.1MB (~550kB gzipped).
Misc
q.min.js is qxWeb. It is jQuery/jQueryUI-like library. Basically, from application development point of view qxWeb has noting to do with normal Qooxdoo flow.
A build created with source-all loads each class, framework and application classes alike, individually - i.e. it loads the hundreds of framework classes one by one (last time I checked, it also loads framework classes which are not used by the application code).
As a workaround, the framework devs have created the job source-hybrid. This one works just as source-all, but creates and loads a concatenation of all framework classes, instead of each class individually (and I think it minifies the framework classes too). Using source-hybrid instead of source-all should improve loading speed significantly.
(What would be great would be the framework devs to add an option to the build* jobs to also generate source maps. But that's not in the generator so far.)
I'm writing a web-based computer game (mainly cakephp, some js only for ui). I need to setup another instantion in other language, and for this I need translations. I translated whole project line-by-line, but this generates problem during bug fixes, also both versions require separate svn repo. I don't want to use gettext, because i have very limited server resources, and I don't want to do this live, during execution. They are separate instances anyway, so I need rather a parser that generates copy of a template project depending on file woth translations. Otherwise i will have to write it myself. Anybody knows such a program?
Looks like you didn't read the Internationalization & Localization chapter on cakephp manual.
I have a project that loads 3rd party modules (in the form of DLLs) and allows them to execute arbitrary code. The application loading the modules requires elevated privileges as so too will the modules.
The modules are all made in house for this project, so the risk is relatively low at the moment. However, in the future there might be outside modules needing to be loaded.
The modules don't have any need to modify, access, or do anything with any of the drives, so I would like to be able to disable any form of I/O in the modules. I haven't figure out any way to do this, or even where to start.
The dependency injection is from MEF, specifically using the Prism design patterns.
You should have a look at these questions:
How can I use CAS in .NET 4 to lock down my MEF extensions?
Looking for a practical approach to sandboxing .NET plugins
As well as the linked http://msdn.microsoft.com/en-us/library/bb763046.aspx
The short story is that if your application is running in full trust, then code access security attributes won't prevent addins from doing anything that they like. You'd need to load the addins in a security-limited (sandboxed) AppDomain and access them via intra-appdomain remoting. To do that, see "Sandboxing" here: http://msdn.microsoft.com/en-us/magazine/ee677170.aspx
I would like to know what are the industry standards or suggestion on how are you doing at your end for following situation.
I am creating multiple silverlight projects which get publised at different dates. All these projects uses varios shared code (common dlls). These shared code would be used in client side or server side. My question is, if the shared code changes would you recompile all the afftected project and release or recompile only when you are making change to the actual code which uses the shared component?
For now, client side, we create a assembly reference folder in each silverlight project and put the latest required dlls in it. By doing it, it has all required files in the XAP itself and it will not conflict with other projects and it works fine. With this approach I will not rebuild any other client side code just because common dll changed. If the common dll change is required for multiple projects then drop the latest copy in all affected projects and build them and distribute them.
On the other hand, the server side (Domain Services using EF), all the service code sit under bin folder of the web site. So if i would make a change to a common dll, then not only I need to publish the latest common dll for current project to work, but also recompile all the other services to use the new dll.
Would like to know your opinions and suggestions.
Thanks
There are two approaches possible:
Add Common Code to the solution and have a project reference
Get the build process to build to a folder and reference from there
I prefer first option. I always build and debug using the latest code and do not have to worry about stale references. I have used the second approach in the past and it is messy and can waste your team's time going after debugging bugs that do not exist (old version referenced). In fact I remember Visual Studio sometimes would not get a later version when it was available.
Another alternative for your Silverlight projects would be to use MEF to dynamically download a XAP file containing the common libraries. Then if the common libraries change, you could publish an updated "CommonLibraries.xap", and your Silverlight clients can pick up the refresh independently of the rest of the Silverlight application.
You could follow the same approach with other projects that use these common libraries. The applications could dynamically load the common libraries so that the common libraries can be refreshed independently.
If possible, consider consuming the "common library" code via WCF services.
How can I organize multiple Composite WPF applications so that they share a single Shell project but populate their module catalogs from different App.config files?
I am writing a suite of applications using Composite Application Guidance for WPF. Each application's functionality is determined by the availability of different modules, which are listed in the Shell's App.config. By giving each application a different App.config, I can specify which modules each application may use.
However I would like to share a single Shell project between all of the applications for common look and feel. Initially I created a Solution for each application, added the Shell project, and then added the relevant modules. The problem is that the common Shell project only has one App.config file, and I cannot change it on a per-Solution basis.
Populating the catalog through code does not avoid this problem--there would still be application-specific code in the Shell that must somehow be activated by the Solution I am using.
What I decided to do was to treat the Shell as its own module. Each application has its own solution and project, which contain the individual App.config files. They also have their own Bootstrapper classes. The Bootstrapper in each application instantiates the Shell.
Apart from hard coding modules, and loading modules from the configuration, you can also load modules dynamically from a given directory.
So to set up different "apps" that all use the same shell, I'd create a batch file that copies the right modules for each app to separate folders, thus creating the different applications.
The Composite Guidance Library documentation has more on setting up your project to load modules dynamically from a directory.