gmane.comp.web.dojo.devel

Re: Latest progress on gridx and its position & promotion

Dylan Schiemann — 2012-05-22T17:17:48

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Evan,

Comments inline.

on 5/22/12 8:32 AM (GMT-07:00) Evan Huang said the following:

What's the core size?


Does this still share dgrid's plugin mechanism? If so, I think that's
worth mentioning.


It's nice to see this many demos. The demo to create a grid in one page
is a cool idea, would be great to see that simplified a bit:

* easier to understand feature names (perhaps basic and advanced sections)
* selecting all modules seems to break things
* would be nice to receive a code fragment to include in your app for
the grid you create.


Do you have any performance tests or metrics for this?


Care to compare with dgrid?


Want to add dgrid to the list? See dgrid features listed at
http://dojofoundation.org/packages/dgrid/


Is this basically saying which features might break other features?


I think it's important that end users have a clear understanding of
both, otherwise it's just another choice to make. Right now, a lot of
the text around it doesn

Latest progress on gridx and its position &promotion

Evan Huang — 2012-05-22T15:32:28

With last time's agreement having two grid projects each targeting
different goals and requirements, we have been spending considerable
efforts improving the gridx component. And it's now having a much
better shape approaching its v 1.0 beta2 -
https://github.com/evanhw/gridx

(- Please see the previous discussion< at >
http://thread.gmane.org/gmane.comp.web.dojo.devel/15990/focus=15991)

So I would like to take this chance to introduce some details of gridx
and discuss how we shall position, promote and keep improving it.

As we discussed previously - for a short summary, gridx is consisted of:
- A compact and lightweight core
- A flexible plugin machinery with comprehensive module life-cycle and
conflict management
- A rich and extend-able set of modules which can be loaded on demand.

The gridx demo gallery provides a nice way to quickly try out the
latest features -
http://evanhw.github.com/gridx/gridx/gallery/gallery.html

The background rationale of gridx is targeting some complex enterprise
scenario with o

Re: Tickets - CC and formatting,definition correction

Tom Trenka — 2012-05-21T16:37:57

If you made a mistake when filling out a ticket, post a comment as a reply
to that ticket.

Normally you don't need to fill out the CC field if you filed a ticket, but
if you're not getting email notifications, odds are you don't have that set
up in your Trac profile--so you might want to check that first.

Both options are a deliberate choice: retaining a full history on a ticket
is a good thing (regardless of whether it seems like noise or not), and the
fact of the matter is that all bug-tracking systems available to the
general public are prone to spam attacks (which is the main reason why we
at DTK require you to sign up before filing any bug tickets).

Cheers--
Tom

On Mon, May 21, 2012 at 11:33 AM, Karl Tiedt <ktiedt< at >gmail.com> wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: Tickets - CC and formatting,definition correction

Karl Tiedt — 2012-05-21T16:33:49

You are always CC'd on tickets you open or reply to...

Not sure if your "formatting" question is related to trac or not...
(the editing options in Trac always worked fine for me)

-Karl Tiedt


On Mon, May 21, 2012 at 11:06 AM, Sasha Firsov <suns< at >firsov.net> wrote:

Tickets - CC and formatting,definition correction

Sasha Firsov — 2012-05-21T16:06:29

Hi all,
Following http://dojotoolkit.org/get-involved just created ticket 
<http://bugs.dojotoolkit.org/ticket/15380> but was not able to set CC 
field with own email. It simply is not available.
Could someone, please, fix either ticket wiki or add CC field?

Also noticed screwed wiki formatting. Bug in wiki?
The text is not editable once posted :(

Thanks,
Sasha


_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

module summaries

Bill Keese — 2012-05-21T10:35:09

A lot of our modules have dueling summaries, ex:

define(["./_base/kernel", "./_base/lang", "./_base/array",
"./_base/connect", "./query", "./ready"], function(dojo, lang, darray,
connect, query, ready) {
// module:
// dojo/behavior
// summary:
// TODOC


dojo.behavior = new function(){
// summary:
// Utility for unobtrusive/progressive event binding, DOM traversal,
// and manipulation.
...

We should get rid of one or the other.    They essentially describe the
same thing.

Any opinions on whether the summary should be at the module level (ie, the
very top), vs. inside the returned object?

Perhaps occasionally it needs to be at the top, for modules returning
strange values like strings or numbers or builtin methods:

define([], function(){
    // module:
    //       jsonparse
    // summary:
    //     function to parse json

    return JSON ? JSON.parse : function(){ ... };
});
_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mai

Re: metadata/docs embedded into code

Chris Mitchell — 2012-05-19T19:44:02

There's the abandoned dojox/help project that I think gave access to docs
at runtime.  Hasn't been updated in quite a while, but is that close to
what you need?

On Fri, May 18, 2012 at 4:43 PM, Sasha Firsov <suns< at >firsov.net> wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: dojo/request

Kitson Kelly — 2012-05-19T10:00:00

Took me a bit longer than I had wanted, but it is now complete and
available on livedocs.

The examples won't work until livedocs gets a refresh of Dojo from trunk
(which I took the action to do but am still figuring out how to, but they
work on my local machine).  It would be very useful though to check over my
documentation, because all of it was "derived" from reading the code.  The
main page is: http://livedocs.dojotoolkit.org/dojo/request and each of the
sub modules that are designed to be consumed publicly are linked from there.

On 24 April 2012 08:23, Kitson Kelly <kitson.kelly< at >asseverate.co.uk> wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: metadata/docs embedded into code

Sasha Firsov — 2012-05-18T20:43:16

Do you think  there is a way to use JSDoc in run-time?
Like XHR JS file and parse it on the fly in browser.

JSDoc 3 <https://github.com/jsdoc3/jsdoc> - written in JavaScript 
(Rhino). Perhaps it should be modifiable to run in browser.
Thinking of effort, JS-based implementation looks easier to implement.

On 2012-05-18 12:58, Bill Keese wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: metadata/docs embedded into code

Bill Keese — 2012-05-18T19:58:09

I don't think so.   If we changed the doc format, it would probably be to
use JSDoc, since that's the standard.

On Sat, May 19, 2012 at 2:03 AM, Sasha Firsov <suns< at >firsov.net> wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

metadata/docs embedded into code

Sasha Firsov — 2012-05-18T17:03:38

...reposting (due to large email size it was returned)

It perhaps is not coincidence that on 3 completely different tiers of my 
app met the need in subj.
CLI, web services and widgets are implemented in different programming 
languages but regarding documentation, all would need to tie docs to 
objects. Perhaps it is not usual app requirement. Extensibility by 3-rd 
party and automated use are making the runtime discoverability, 
versioning and documenting high priority. Curious that DKT fits there.

In the life cycle of dijit I am facing same problem as on other app 
tiers. Even without in-browser widget designer there are several use 
cases when docs needed in run-time. One of them is DOH testing pages.

My issue is absence of docs during run time. In Java it is achievable by 
annotations(< at >...). In JS one of solutions would be injection of  
docs/metadata to object or its prototype.


Have metadata/documentation as javascript fields ever been considered as 
DTK option?

Sasha

Sample as an idea

declare(

Re: Parser Enhancements

Kitson Kelly — 2012-05-16T21:01:28

Right now a declarative build profile would look something like this:

var profile = {

    buildDeclarativeLayer: true,

    layers: {
        "dojo/dojo": {
            include: [ "dojo/dojo", "parserAutoRequire/src" ],
                customBase: true,
                boot: true
        }
    },

    resourceTags: {
        declarative: function(filename){
            return /\.htm(l)?$/.test(filename);
        },
        amd: function(filename, mid){
            return /\.js$/.test(filename);
        }
    }
};


I think leveraging the tagging mechanism makes the most sense.  I need to
check though on how the layers are handled internally...  Adding a new
property might be more heavy lifting on the internals of the
buildController than it stands right now.  I would personally like to have
something that said "build these dependencies into this layer" and "these
into that" but the path Rawld and I came up was the this.  I like your idea
Ben, it is just that I can't see the "path" of how to accomplish it

AUTO: Si Qi Zhong is out of the office.(returning 05/18/2012)

Si Qi Zhong — 2012-05-16T20:04:06


I am out of the office until 05/18/2012.

Si Qi Zhong is out of the office. I will respond to your message when I
return.


Note: This is an automated response to your message  "Re:
[dojo-contributors] Parser Enhancements" sent on 17/05/2012 3:24:41.

This is the only notification you will receive while this person is away._______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: Parser Enhancements

Ben Hockey — 2012-05-16T19:52:05

inline

On May 16, 2012, at 3:24 PM, Kitson Kelly wrote:

an idea…

do the declarative resources get a module id or have some way to reference them in the definition of a layer?

layers: {
  "my/declarative/layer": {
    declarative: [
      "my/resources/foo.html",
      "my/resources/bar.html"
    ]
  }
},

you can then process the "declarative" array with some logic that understands these declarative ids?  it's been a while since i've dug into the build transforms so i can't remember if i'm asking the impossible or not.  it would seem this approach would rather cleanly answer all of your questions:
 - no need for a buildDeclarativeLayer option, the presence of a declarative array in a layer definition is that trigger
 - no need for a module it, it comes from the id of the layer
 - as above

in addition, this would allow someone to potentially build multiple declarative layers - e.g. a multi-page site that wanted a unique declarative layer per page with a base layer that's included on all the pages.  it

Re: Parser Enhancements

Kitson Kelly — 2012-05-16T19:24:41

I plan to talk about this tonight, but essentially I just finished creating
the transform for the builder that will scan for auto-require and
declarative require dependencies in any resources tagged at declarative
(thanks to Rawld providing moral and technical support).

There are just a couple of finer points that likely need some wider
conversation:

   - The transform by default will build any dependencies into the
   "dojo/dojo" layer.  There is a build profile option called
   "buildDeclarativeLayer" when set to true will build a layer with any build
   dependencies.  Is the name of this option agreeable?
   - As far as I understand it, there is no easy way to build multiple
   layers and say these declarative resource dependencies go into this layer,
   etc.  Therefore there should be a default MID created for the layer.
    Currently I have "declarative/layer" which means the layer gets built as
   "{release_path}/declarative/layer.js".  Is this agreeable?
   - I could provide another profile config o

Re: 1 HTML file for UI test under DOH?

ben hockey — 2012-05-16T02:36:47

we have the dojo-interest mailing list for user support and this  
mailing list is for the development of dojo.

why do i mention this?  because it's possible someone else will have  
your exact same question in the future (and has probably already asked  
it in the past).  if someone was searching for conversations regarding  
this kind of thing we would tell them that they should be looking on  
the dojo-interest mailing list.  if we answer questions here, we're  
only hurting ourselves because we will need to repeat our answers in  
the future.  it does not scale well for us to offer support on this  
mailing list.

for this same reason, we don't answer questions in our bug database -  
it's just for reporting bugs and tracking development.

thanks,

ben...


On May 15, 2012, at 10:01 PM, Sasha Firsov wrote:


_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

1 HTML file for UI test under DOH?

Sasha Firsov — 2012-05-16T02:01:33

Just thinking aloud. Passed over UI test using DOH and been quite upset 
by complexity and hard to find single guide on subject.

Since I would have to write few dozens of dijits with own tests, it 
would be wise to create common and easy template for it.
Is somewhere a decent template or at least guide which allow to use 1 
and only *1 HTML file for UI test under DOH*?

 From what I see, for single achoo of test dijit author needs to create 
and tune 4 files . 2 HTMLs and 2 JS.

There some thoughts on
- reusing same HTML for forwarding to runner and displaying inside of 
IFRAME;
- reusing test JS for doh.registerUrl() and doh.register( [testFunc] )
But no idea *how to feed HTML to runner instead of JS*?

doh/_parseURLargs.js has magic parameter *testUrl *for runner.html
But from source it is not clear whether HTML URL could be used there.

from http://trac.dojotoolkit.org/ticket/5149, Bill was able to run 
http://localhost/trunk/util/doh/runner.html?testModule=tests.html
But I guess the meaning was to run t

Re: bindr/Re: is there a need for dojo/css! or dojo/less! AMD plugin?

Bill Keese — 2012-05-16T01:25:21


It's a fair question...

Presumably you mean that stylesheets will work as intended regardless of
what order they are loaded in.   That sounds nice in theory, although I
worry about how to detect ties:  If two stylesheets have a tie, the
regression tests may not detect the problem since it's a race condition.

If you somehow solve that problem, then it's just a question of making sure
the claro stylesheets override anything in dijit.css, and that RTL
stylesheets override the LTR ones (ex: that Dialog_rtl.css will override
Dialog.css even if Dialog_rtl.css is loaded first).




I don't think dijit stylesheets pollute any common namespace, except maybe
for claro/document.css, for styling the entire document.
_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: bindr/Re: is there a need for dojo/css! or dojo/less! AMD plugin?

Sasha Firsov — 2012-05-16T01:08:29

While we are not tied to any implementation, may be we should consider 
independence of order as one of requirements?
It would be strange if any dijit will pollute the common namespace. Why 
style is so relaxing than? I know the answer... But should we encourage 
the stylesheet be written in same strict convension as JS?

 From DTK as framework I would expect some discipline and framework 
enforcement. If style is messing with others by order or simply by own 
presence, it should create a huge warning during compilation and debug.

IMO there is a way to write CSS properly. And we should guide DTK users 
to use it properly on each possible level. On Guideline, in compiler, 
during debug and running withing test framework.
Perhaps it is not easy with CSS as it is not designed for large modular 
development. That is when artificial style languages could help.

Meanwhile proposal was to keep theme CSS as only common DTK dependency 
and give user's digits define dependencies on own specific for them 
CSS-es. With

Re: bindr/Re: is there a need for dojo/css! or dojo/less! AMD plugin?

Bill Keese — 2012-05-16T01:07:21

Well that's certainly annoying.    I think you could still work around it
though, be reinserting that <style> node (or a new <style> node with the
same content) after the link.

On Wed, May 16, 2012 at 9:53 AM, Kris Zyp <kzyp< at >dojotoolkit.org> wrote:

_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

Re: bindr/Re: is there a need for dojo/css! or dojo/less! AMD plugin?

Kris Zyp — 2012-05-16T00:53:09

IIRC, in IE if you try to place a <link> in the document after other
stylesheets have loaded, even if you place it before these stylesheets
in the document order, IE will treat it as the overriding. For example:

<script>
require(["dijit/Tree]); // async
</script>
<!-- once loaded, the CSS loader tries insert the <link> here, but in IE
it is still treated like it came after the style element below-->
<style>
.tundra .dijitTreeIsRoot { /* user expects this to override the
Tree.css's rule*/
    background-color: green;
}
</style>

Anyway, I could be remembering incorrectly, but I believe that was the
issue.
Thanks,
Kris

On 5/15/2012 6:39 PM, Bill Keese wrote:


_______________________________________________
dojo-contributors mailing list
dojo-contributors< at >mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors