dmachi / dojox_application Goto Github PK

Build system should be extended to support dojox/app JSON config (i.e. automatically look up in their to build the corresponding source files).
Some issues with build should be investigated and fixed. For example the fact that dojox/app automatically maps “./” modules to an “app” module might cause problem to load “built” files.

The View destroy method is AFAIK never called.

Hi,
I'm currently trying to do a build of our dojox/app application and am using the dojo-boilerplate as a starting base.
I can get the build working although when I try and go into my index.html I get the infamous :Error: declare: mixin #1 is not a callable constructor. on ln 109 of dojo.js ( which is now compressed ).
I know this is probably not an issue and I'v given a hugely brief overview of my problem, but before I start picking stuff apart I thought it wise to ask if there was a "preferred way" of doing a dojox/app build?

Many thanks,
Stephen.

File structure -
webapp/
/build.sh
/profiles/app.profile.js
/src
/app <- contains standard app structure
/app/run.sh <- contains package info for the build
/dojo
/dijit
/dojox
/util

I'm working on a desktop application using the dojox.app framework. I realize it is not suitable for this job just yet, so I'm trying to raise some points here that I think are relevant in the ongoing work to make it applicable to desktop applications. I must apologize in advance if I got something wrong at an understanding level, most of this is pretty bleeding edge and not very deeply documented so I could definitely be wrong here.

In this issue, I'd like to focus on the View class, specifically the _startup() method:

1. For child views, the region is basically always set to center. I think that in order to enable the kind of composite views a desktop app requires, more flexibility is required - e.g. perhaps giving the parent the ability to specify "openings" or regions where children views would be put. Not sure how this could/should be done currently.
2. The inline setting of the style to "width:100%; height:100%" - for me it has caused issues since it overrides my own style declarations (e.g. a page that would otherwise be properly laid out, got out of hand because this overriden my CSS defs. I'd suggest giving this reasonable default behavior, but allowing people to avoid having these style settings applied, so they can match their specific needs - and documenting how all of that should be done.
3. Additionally, I don't think the overriding of the IDs of the view elements is a good practice. I can imagine why it's needed, so if it is really a must, let me humbly suggested that it be better documented. I'd suggest adding to the relevant document (http://dojotoolkit.org/reference-guide/1.8/dojox/app/view.html): "Note that View will override the created view HTML element with an ID determined by the view hierarchy as specified in the app's configuration. This means you should not set an ID for your views in your templates or rely on your own ID in your CSS or code."

See the error2 test in 667976c

The definition file does throw new Error() and no error is reported in the console as well as the application status is moved to STARTED just as if everything want correctly at application startup.

Note that if the error is in the init() method of the definition file then the application correctly reports error and never goes to STARTED state.

Also once the application reached the STARTED state even if an error occurs during the lifecycle of the application no state will be set to reflect that.

We should be consistent and make it works in both cases.

Be even more flexible in view templates/definition loading:
Allow direct loading of Widget/programmatic views (instead of just HTML templates)

In particular it contains a scene.json while we have merged scenes & views.

Since the default expression character is "$", by default it doesn't work and throws an error in _TemplatedMixin (line ~ 80, { throw new Error(className+" template:"+key); } ) . Of course, if the expression character is set to something different, it works well.

Now, since dojox.mvc.Output is very likely to be often used with the dojox.app framework, IMHO this is rather confusing and should either be fixed or documented appropriately (this is not currently mentioned in the reference docs of dojox.mvc.Output)...

From Issue #42, msmiths wrote:
Hi Ed,

So I see the generated id when I am debugging my application... and I have also had to write a helper function to allow me to find a given view within my application, starting at the application level since I know the name of this global.

In the Chrome Developer Tools debugger, I can see that id of the view is constructed using the id of the application and the ids of the all of the views in the chain. This is also used as the key in the associative array used to store the views in the "children" attribute of the objects. So, my helper function looks like this:

_getView : function(app, childViewName) {
    var view = null;
    if (app && app.children) {
        for (var name in app.children) {
            if (name == childViewName) {
                view = app.children[name];
                break;
            } else {
                view = this._getView(app.children[name], childViewName);
            }
        } // FOR
    }
    return view;
},

I can also see that the "name" attribute for the view objects is just as it appears in the configuration... so I could have implemented the helper function to take an array of view names and used those to walk the hierarchy of view objects, but I thought that using the id was simpler.

Either way... my assertion remains that I should not have to understand the structure of my application in order to construct the id for a given view, I should be able to specify the id that I want to assign to each view as part of the configuration for that view. Also, I should not have to implement my own helper functions to navigate objects in the framework... the relevant application and view classes should provide the relevant functions that allow me to find views (or other framework objects such as models or stores) within the hierarchy.

Thanks.
Martin.

See:

constructor: function(params, node){
  lang.mixin(this, params);
  this.params = params;
  // ...
}

This seems redundant. I think only params should be kept the mixin is dangerous. For example Application defines a controller object that contains the instances of controllers and the config also contains such a property.

You shouldn't have the brackets here, right?

topic.publish("app/history/back", [{"viewId": currentHash, "detail": detail}]);

topic.publish("app/history/forward", [{"viewId": currentHash, "detail": detail}]);

topic.publish("app/history/go", [{"viewId": this._current, "step": step, "detail": this._historyStack[index]["detail"]}]);

Looks like a holdover from the dojo.publish() syntax.

I received the following email about this bug:

We are having a very hard time getting slide transition to work properly, It always slides forward (transitionDir = 1) no matter what we do. The only way to get it to slide reverse is to trigger a transition using dojox.app and setting reverse: true

(this.app.trigger("transition", {"viewId": "phone,ViewAppLists","opts": {reverse: true}});). Doing it via a toolbar button is not working:
        <span dojoAttachPoint="backButton"
                data-dojo-type="dojox.mobile.ToolBarButton" data-dojo-props='arrow:"left", moveTo:"${moveTo}", target: "${moveTo}", transitionDir:-1'
                style="float: left; visibility: hidden; z-index: 1;">${back}
        </span>

I went to the latest todoApp demo and replaced all the "fade" with "slide" and noticed that the todoApp has the same problem. The Back button slides the wrong way.

This can be reproduced on the todoApp. This apparently comes from the Layout controller that only listens to onresize not onorientation change.

See more details in cjolif/dojo-todo-app#86

for example: in the configuration file startView="items,list" and defaultView="items,date", directly visit "#items,list" will cause layout failed.

This issue was raised here:
cjolif/dojo-todo-app#102
by maitriyogin:

Setting mblHideAddressBar and mblAlwaysHideAddressBar to true hides the address bar.
However the containers are not resized to with the new space.
It seems that the layout is done before the address bar is hidden..
Any ideas?
Cheers,
Stephen.

I have recreated the problem.

Currently templates & definitions are loading using AMD in "app" AMD module. "app" is automatically configured to be the application root. This allows to specify path to templates & definition relatively. This is good. However one might want to load templates in a totally different module. For example one might want to load "mylibrary/templated/Whatever.html". This is not feasible as of today.

A solution is to prepend the "app" module only for relative paths, i.e. paths that start with ./. Other paths are used as-is by AMD loader. See:

https://github.com/cjolif/dojox_application/commit/a5fa4606e0dc9031074f93d5050134115f7fd3f7#diff-0

This comes from this code in View.js

            }else if(this.definition){
                var index = this.definition.indexOf('.js');
                if(index != -1){
                    path = this.definition.substring(0, index);
                }
            }else{

It should probably be a bit smarter.

Currently the way the domNodes are being appended in main.js and View.js do not allow the Layout controller to support dojox/mobile/FixedSplitter and ScreenSizeAware.

There is a scrollable regression on iOS6 with dojox/mobile see ticket 16038 http://trac.dojotoolkit.org/ticket/16038 which also occurs on dojox/app.

The fix for this will be to remove dojox/app/widgets/scrollable.js (which was originally copied from dojox/mobile/scrollable.js and modified) and to use dojox/mobile/scrollable.js instead.

use HistoryHash controller to do history management on Android 4, and set the defaultView has more parts like defaultView="main,main"

1. open multiScene test application
2. transition to another view like "tabScene,tab1"
3. click back button to back to "main,main" view
   application will throw "child view must be loaded before transition" error.

This error is caused by:

1. the initial history hash is empty when application start
2. when back from hash "tabScene,tab1" to the empty hash, Transition controller will get the defaultView as the transition to view
3. the defaultView="main,main", so get the transition to view by "next = parent.children[parent.id + '' + 'main,main'];" failed.
   the correct one should be next = parent.children[parent.id + '' + 'main'];"

This issue include two parts:

1. not set defaultTransition, dojox.app will use transition = "none" and it cause application failed because the return value of dojox.css3.transit is undefined. This is an issue of dojox.css3, see ticket: http://bugs.dojotoolkit.org/ticket/15429
2. only set the application level defaultTransition, the third level child cannot adopt the application level defaultTransition because the third level child will get defaultTransition from the second level child. This is an issue of dojox.app Transition controller. Need to fix in Transition controller.

"dojox/app/widgets/Container" with data-dojo-props="scrollable:'true'" is not working with a fixed header. When it is used under a header and it is scrolled, it will scroll back to the top. It should also work with a fixed footer.

When launching an application the initial display does not go thru _doTransition which causes a couple of problems.

1. the default view beforeActivate and afterActivate are not called
2. When transitioning away from the initial display beforeDeactivate and afterDeactivate are not called, which causes problems

see issue cjolif/dojo-todo-app#71

use require module instead of global require to avoid doc parser to fail

define(["dojo/_base/declare", "dojo/_base/lang", "dojo/Deferred", "dojo/when", "require"],
function(declare, lang, Deferred, when, require){
    require.on(......);
});

Let's assume I am using a model object with some simple business logic inside it, for instance an isValid() method, and I'd like to use EditModelRefController to manage this model object.

Since EditModelRefController.reset() uses cloneModel() internally, a call to reset() results in a new object managed by the EditModelRefController instance - where this new data object indeed has the same data fields as the original - but one that does not contain the isValid() method. This causes any controller code which relies on such business methods to malfunction.

I'm not yet sure what would be the most appropriate way to handle this in practice, but I think it's a very real concern when implementing apps.

This may already be possible, but I haven't found a good example:

We need to be able to specify attachPoints and attachEvents on the "controller" modules that correspond to the template files, just like Templated "dijit" works.

I'd like attachPoint properties exposed on my controller module to be bound to corresponding attach points in the template, and functions exposed on my controller to be bound to attachEvent specified in the templates. This would make it much easier for controller code to reference important child elements in the templates and respond to events from those child elements in the controller.

See http://bugs.dojotoolkit.org/ticket/13606. I attached a patch a long time ago to that ticket to fix the AMD conversion.

currently you can pass a class name to store.type in the config. The moderm version would be to use an AMD module.

Hi

It was adviced to me I should submit issues here when I found problems related to dojox.app.

I'm facing some problems when switching views.
How to reproduce

1. Go from view 1 to view 2
2. Resize the browser window
3. Go from view 2 to view 1
   -> Now (somettimes) the layout is messed up. After again resizing the browser window the layout is good.

See also http://dojo-toolkit.33424.n3.nabble.com/1-8beta-Sereral-re-size-issues-td3987241.html#a3987364 (issue 3) for used code and screenshots

A priori to be done when moving to 2.0 and separated package (no need to keep compatibility)

• dojox/app/module should probably be module_s_ (be consistent with controller_s_ and after all there are several of them)
• dojox/app/lifecyle.lifecyle.STARTED Sounds like repeating things. Shouldn't the lifecycle flags be statically defined directly on module instead dojox/app/lifycle.STARTED?
• layout gets its own package with just utils modules in there. Maybe it should just be a layoutUtil.js module in the utils package...
• maybe other things

We have had multiple questions about being able to set application data into the url to allow the sharing of the url correctly.
For example in the todoApp we would like to be able to save the selected listId and itemId in the url, so that when the page is refreshed the previously selected list/item would be displayed instead of the first item in the first list.

This is something that's become more obvious as we've begun to use dojox_application for apps like https://github.com/cjolif/dojo-todo-app and getting feedback from several teams trying to use the latest dojox/app.

The directories views/ and templates/ seem misnamed, based on their role/mapping to commonly known MVC terminology.

The templates in this mvc style are really the View part of MVC.
The js files in the views/ directory of dojox.app projects are really the Controllers logic of MVC.
"Scenes" in dojox.app are really what are commonly known as "Composite Controllers" in MVC terms.

The terminology we should use where this is confusing is coming from what's being taught in universities around MVC...especially modern mobile/iOS development courses. I think we should try to get our overall concepts aligned with what students are being taught that MVC is (really this hasn't changed much since early smalltalk days), so that the mental mapping when they come to dojo is minimal and obvious.

As a concrete example of a course and terminology that's being taught, check out iTunesU-> Stanford University-> Developing Apps for iOS CS193P (2011) course by Paul Hegarty, specifically the second part of Lecture 1: MVC and Lecture 6: Multiple MVC's and Segues.

We should be able to describe dojox.app and dojox.mvc with obvious relation to the concepts in these lectures (even though this is a course for native app development, the exact concepts apply to what we're doing).

We should consider renaming the directories to match this more logical mapping. it helps remove the extra made-up term, "templates" that doesn't mean anything in mvc sense.

templates/ ==> views/
views/ ==> controllers/
"scene" ==> "composite controller"

Globalization support. In particular make sure parameters of the configuration (name, description...) can be localized and that the user can specify a nls path in the config for their views

See more details in the 1.9 plan:
https://docs.google.com/document/d/1fe2qm1x_AHidYd2wNkG77tZgFIrvlt-ctGT0rpb-5F0/edit?pli=1#heading=h.cqfn9x4yiu3f

use testapp = Application(jsonRef.fromJson(config)); the return value is null.
In current dojox.app, When application start, create an global namespace various named "app". It's better that application can define the name of the application.
For example:
var myApp = Application(config);
that means Application(config) method should return the application various.

Hi,
this is not really an issue as such but I was wondering if it's possible to use Django as the templating mechanism for the view templates?
This would be very very cool and bring this in line with the all the other mvc spa frameworks.
Cheers,
Maitriyogin

This should probably be consistent and all views created by the controller. That way if the controller is specialized to create other type of views, this will work for the app view as well.

Only when the config requires a DataStore this class should be loaded.

There are times when there can be glitches in the layout where things jump around or change size and or position during the display. The common solution has been for the application to use visibilty:hidden until these glitches are past, and then to set visiblity:visible. We should try to find a way for dojox/app to make this easier for the application developer. It may be possible for a smarter layout controller to make some of that unnecessary.

In todoApp, if I remove mvcModel from the dependencies the application is not initialized correctly anymore (in tablet mode at least). So it seems the dynamic loading of mvc vs simple model is not working correctly. Matybe we should simplify that code and rely on the fact the right dependency is loaded through dependencies array. That would help a future "build" system for dojox/app as well as the build system would "just" have to look for the dependencies instead of looking a various config parameters.

I think the automatic loading of the controllers should be optional, (done by default) so that the application can replace one of those controllers if necessary.
The config section to prevent the automatic loading of the controllers would be as follows, and each of the 3 controllers would need to be specified if "noAutoLoadControllers" : is set to true.

    "noAutoLoadControllers" : true,

    "controllers": [
        "dojox/app/controllers/Load",
        "dojox/app/controllers/Transition",
        "dojox/app/controllers/Layout",
        "dojox/app/controllers/History"
    ],

The non-function values aren't documented correctly, see http://bugs.dojotoolkit.org/ticket/15440 and http://bugs.dojotoolkit.org/ticket/15438.

Reproduced on Chrome, Windows 7.

This is not HTML5 compatible. It should be something like data-app-region.

See this link in the 1.9 Plan document for more details:
https://docs.google.com/document/d/1fe2qm1x_AHidYd2wNkG77tZgFIrvlt-ctGT0rpb-5F0/edit?pli=1#heading=h.wslte22n4qh8

Allow a configuration file to share common configuration for example for tablet & phone application without having to copy/paste in 2 configuration files most of the config

( Note: My disclaimer from the previous issue applies here as well. I'm doing my best to point out the relevant stuff, but could certainly be missing the mark in one way or another. )

Right now, trasitionOptions can only be used can be on dojox/mobile widgets which inherit from dojox/mobile/_ItemBase. There needs to be a way for this to work well in desktop apps as well.

Support for composite views (where i.e. a view can have two children, and each child initiates a transition to another view within the space of that child) would be very nice as well.