Re: Dojo-interest Digest, Vol 123, Issue 4

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Dojo-interest Digest, Vol 123, Issue 4

Dazza
UNSUBSCRIBE

Darryl Wilson

p +64 4 499 3546
m +64 27 566 1551
www.e-spatial.co.nz

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, 3 March 2015 10:10 a.m.
To: [hidden email]
Subject: Dojo-interest Digest, Vol 123, Issue 4

Send Dojo-interest mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Dojo-interest digest..."


Today's Topics:

   1. Re: pwCheck function in PasswordValidator (Harry Devine)
   2. Re: pwCheck function in PasswordValidator (Harry Devine)
   3. Re: Dijit styles when running two Dojo versions (zcurtis)
   4. Re: pwCheck function in PasswordValidator (Fred Duarte)


----------------------------------------------------------------------

Message: 1
Date: Mon, 2 Mar 2015 20:48:15 +0000 (UTC)
From: Harry Devine <[hidden email]>
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Well, I'm defining my button on my page as follows (the main js file has already been included at this point):

<button data-dojo-type="dijit/form/Button" type="button"> Show Account Info <script type="dojo/on" data-dojo-event="click" data-dojo-args="evt"> validateUserEntered(); </script> </button>

So I believe I'm already using dojo/on, so why wouldn't the function be found in my js file?

Thanks,
Harry
----- Original Message -----

From: "Stephen Gevers" <[hidden email]>
To: [hidden email]
Sent: Monday, March 2, 2015 2:25:58 PM
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator

validateUserEntered is defined in the scope in which it was declared?that means it?s only defined inside the callback function for require. Without knowing how you are trying to use the function, it?s difficult to say how to fix it. The idea behind AMD is to limit the pollution of the global name space. As Karl pointed out, it may not be the best idea to make the validateUserEntered function global. However, it is easy to do?simply set window.validateUserEntered equal to your function inside the require callback. However, there are still timing issues. window.validateUserEnetered will not be defined until the require callback is executed. And the callback won?t be executed until all of its dependencies have been loaded. So it?s possible that the loader could still be trying to load ?dijit/registry? when you are wanting to use window.validateUserEntered. It?s unlikely if you are waiting on user input before attempting to use the function that the loader wouldn?t have completed
  this task. But it?s important to understand that some unknown amount of JavaScript code can be executed before the callback for this require is invoked.

My best guess is that you have some JavaScript attached to a DOM element; for example, an onclick attribute on a button. In this case, you are probably calling some function that has to be defined in the global namespace and that?s why you have gotten hung up on the nesting order of require / function def. A better way might be to add some code to your require that uses dojo/on to attach a function to that button. Since the function you would be attaching to handle the click event would be declared in the same scope as validateUserEntered, you wouldn?t need it to be global.

Steve




On Mar 2, 2015, at 12:54 PM, Harry Devine < [hidden email] > wrote:

OK so I'm trying to understand what I've read and the examples given. I have restructured my main js file to be similar to below:

require([
"dijit/registry",
"dojo/dom",
"dojo/Deferred",
], function (registry, dom, Deferred){

function validateUserEntered() {
// check user entered here
}
// other functions here!
});

The problem I'm running into is I get an error stating that validateUserEntered is not defined. This was the reason why I had the requires in each subfunction because doing it this was, as was suggested, wouldn't work and would give me these type of errors. So how do I go about making this work? I'm moving towards using Deferred on my async functions as was suggested, but in order to get to that function in my execution chain, I have to get this working first.

Thanks!
Harry

----- Original Message -----

From: "Karl Tiedt" < [hidden email] >
To: [hidden email]
Sent: Friday, February 27, 2015 7:50:55 PM
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator

Inline, because the wording on this response leads to so many possible misconceptions... And lets be honest, ambiguity is no help to comprehension. Harry, you would benefit greatly from looking over this link regarding Deferreds, http://dojotoolkit.org/documentation/tutorials/1.6/deferreds/ 

-Karl Tiedt

On Fri, Feb 27, 2015 at 12:16 PM, Stephen Gevers < [hidden email] > wrote:

<blockquote>

Harry?You?re going to have to really think through what?s happening at each line. Notice that where you are returning the deferred is inside the require call back function. The checkPassword function has no return value.




Harry, this is the key problem with doing inline requires the way you were writing yours.

<blockquote>

Any return from the require call back function is ignored.

</blockquote>


This is a very broad statement, if returns from require callbacks were ignored, AMD would never work... In this particular case, yes the return is ignored because we never exploit it.

<blockquote>

That?s the basis of what your problem is below. But you seem to be missing the async/deferred/promise concept all together. And require fits right into that async concept. When you call checkPassword, the callback function to required will not necessarily be called before the call to checkPassword returns.

</blockquote>


That is also an overly generalized statement, the require() callback *HAS* to complete before the checkPassword call "returns" assuming that "returns" means resolves... If by "returns" you mean "go to the next line of code to execute" then you are correct, the entirety of the checkPassword function will complete after that.

<blockquote>

Assuming you need your function to be globally defined, you would rework your code to something like this:

</blockquote>


Lets not assume this, because we would much rather teach GOOD practices.

<blockquote>

require ([?dojo/request?, ?dojo/Deferred?], function (request, Deferred) { window.checkPassword = function (password) { // checkPassword body here?now you can return a Deferred, which will be the result of calling the function, like you have below }; });

Note that you can?t assume that the checkPassword function is available yet! If the next line of code after this require was to call checkPassword, it would probably fail.

</blockquote>


Aside from not promoting bad habits I have to say, HUH? You just defined checkPassword, it is absolutely safe to assume it is define... Maybe Harry isn't the only one who could use some practice in async behavior ;)

<blockquote>

For this reason, it would be better to define checkPassword as its own AMD module.

</blockquote>


Yup, you should definitely spend some time reviewing how this works as well... Breaking a single function out into it's own module does nothing to help improve your knowledge of "when its available", and unless this single function is worthy of its own module, you are just creating additional overhead.
Here is a fully commented example of how I might right the code with some assumption that this is the executed JS file, not part of a modular piece of code (pastebin here: http://pastebin.com/1KiVHSuv )

require([
"dijit/registry",
"dojo/request",
"dojo/Deferred"
], function(registry, request, Deferred) {

// NOTE: This is written as if it is not a module, but your main JS file that gets executed on page load...
// checkPassword would NOT be a global method so you would be calling it from some sibling code inside this file...

function checkPassword(password) {
var dfd = new Deferred(); // Create a deferred object that we will resolve at a later time
console.log("c1: inside checkPassword()"); request.post("checkPwd.php", { // Make XHR Post request to checkPwd.php
handleAs: "json",
data: {
'user': registry.byId("username").get("value"), // accessing .value isnt the best practice either, should almost always use the getter/setter
'pwd': password
}
}).then(function(data) { // Our XHR request completed... lets check the status and see if its a success or a failure
console.log("c2: checkPassword() response", data); if (data.status == "true") {// Success!
console.log ("true");
dfd.resolve(data); // Resolve our deferred object with the data from the XHR response incase we want to expose the results from the promise } else { // Failure!
console.log ("false");
dfd.reject(data); // Reject our deferred object again with the data from the XHR response so that you could tailor an error message or something from it } });

return dfd.promise; // Return the deferred's promise which is then'able.
}

// For demo purposes I have added a console message in each stage of the Async process and I have numbered them in the order they are written in code just to help illustrate the round about way Async happens c# are generated by code in checkPassword and m# are from the code surrounding the checkPassword call

console.log("m1: before checkPassword()"); // NOTE: To use this method you would then do something like this... and since we used resolve and reject you could do this checkPassword(yourPass).then(logThemIn, kickThemOut); // What this means is if checkPassword success, pass its data to LogThemIn() else pass the failure data to kickThemOut()
console.log("m2: after checkPassword()"); });


--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/ 

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest 

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/ 

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest 

</blockquote>



--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/ 

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-interest/attachments/20150302/a952c666/attachment-0001.htm 

------------------------------

Message: 2
Date: Mon, 2 Mar 2015 20:50:34 +0000 (UTC)
From: Harry Devine <[hidden email]>
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

I just tried your suggestion and it didn't work. Same error.

Thanks,
Harry

----- Original Message -----

From: "John Norris" <[hidden email]>
To: [hidden email]
Sent: Monday, March 2, 2015 1:58:54 PM
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator

You can do this:


var validateUserEntered = null;

require([
"dijit/registry",
"dojo/dom",
"dojo/Deferred",
], function(registry, dom, Deferred){

validateUserEntered = function() {
// check user entered here
}

// other functions here!
});


That puts validateUserEntered in global scope, and therefore accessible from anywhere. Of course, if you try to call it before it's set, you'll have other problems.


On 3/2/15 10:54 AM, Harry Devine wrote:

> OK so I'm trying to understand what I've read and the examples given.
> I have restructured my main js file to be similar to below:
>
> require([
> "dijit/registry",
> "dojo/dom",
> "dojo/Deferred",
> ], function (registry, dom, Deferred){
>
> function validateUserEntered() {
> // check user entered here
> }
> // other functions here!
> });
>
> The problem I'm running into is I get an error stating that
> validateUserEntered is not defined. This was the reason why I had the
> requires in each subfunction because doing it this was, as was
> suggested, wouldn't work and would give me these type of errors. So
> how do I go about making this work? I'm moving towards using Deferred
> on my async functions as was suggested, but in order to get to that
> function in my execution chain, I have to get this working first.
>
> Thanks!
> Harry
>
> ----------------------------------------------------------------------
> --
> *From: *"Karl Tiedt" <[hidden email]>
> *To: *[hidden email]
> *Sent: *Friday, February 27, 2015 7:50:55 PM
> *Subject: *Re: [Dojo-interest] pwCheck function in PasswordValidator
>
> Inline, because the wording on this response leads to so many possible
> misconceptions... And lets be honest, ambiguity is no help to
> comprehension. Harry, you would benefit greatly from looking over this
> link regarding Deferreds,
> http://dojotoolkit.org/documentation/tutorials/1.6/deferreds/
>
> -Karl Tiedt
>
> On Fri, Feb 27, 2015 at 12:16 PM, Stephen Gevers
> <[hidden email] <mailto:[hidden email]>> wrote:
>
> Harry?You?re going to have to really think through what?s happening at
> each line. Notice that where you are returning the deferred is inside
> the require call back function. The checkPassword function has no
> return value.
>
>
> Harry, this is the key problem with doing inline requires the way you
> were writing yours.
>
> Any return from the require call back function is ignored.
>
>
> This is a very broad statement, if returns from require callbacks were
> ignored, AMD would never work... In this particular case, yes the
> return is ignored because we never exploit it.
>
> That?s the basis of what your problem is below. But you seem to be
> missing the async/deferred/promise concept all together. And require
> fits right into that async concept. When you call checkPassword, the
> callback function to required will not necessarily be called before
> the call to checkPassword returns.
>
>
> That is also an overly generalized statement, the require() callback
> *HAS* to complete before the checkPassword call "returns" assuming
> that "returns" means resolves... If by "returns" you mean "go to the
> next line of code to execute" then you are correct, the entirety of
> the checkPassword function will complete after that.
>
> Assuming you need your function to be globally defined, you would
> rework your code to something like this:
>
>
> Lets not assume this, because we would much rather teach GOOD practices.
>
> require ([?dojo/request?, ?dojo/Deferred?], function (request,
> Deferred) {
> window.checkPassword = function (password) { // checkPassword body
> here?now you can return a Deferred, which will be the result of
> calling the function, like you have below }; });
>
> Note that you can?t assume that the checkPassword function is
> available yet! If the next line of code after this require was to call
> checkPassword, it would probably fail.
>
>
> Aside from not promoting bad habits I have to say, HUH? You just
> defined checkPassword, it is absolutely safe to assume it is define...
> Maybe Harry isn't the only one who could use some practice in async
> behavior ;)
>
> For this reason, it would be better to define checkPassword as its own
> AMD module.
>
>
> Yup, you should definitely spend some time reviewing how this works as
> well... Breaking a single function out into it's own module does
> nothing to help improve your knowledge of "when its available", and
> unless this single function is worthy of its own module, you are just
> creating additional overhead.
> Here is a fully commented example of how I might right the code with
> some assumption that this is the executed JS file, not part of a
> modular piece of code (pastebin here: http://pastebin.com/1KiVHSuv )
>
> require([
> "dijit/registry",
> "dojo/request",
> "dojo/Deferred"
> ], function(registry, request, Deferred) {
>
> // NOTE: This is written as if it is not a module, but your main JS
> file that gets executed on page load...
> // checkPassword would NOT be a global method so you would be calling
> it from some sibling code inside this file...
>
> function checkPassword(password) {
> var dfd = new Deferred();// Create a deferred object that we will
> resolve at a later time
> console.log("c1: inside checkPassword()");
> request.post("checkPwd.php", {// Make XHR Post request to checkPwd.php
> handleAs: "json",
> data: {
> 'user': registry.byId("username").get("value"), // accessing .value
> isnt the best practice either, should almost always use the
> getter/setter
> 'pwd': password
> }
> }).then(function(data) {// Our XHR request completed... lets check the
> status and see if its a success or a failure
> console.log("c2: checkPassword() response", data); if (data.status ==
> "true") {// Success!
> console.log ("true");
> dfd.resolve(data);// Resolve our deferred object with the data from
> the XHR response incase we want to expose the results from the promise
> } else {// Failure!
> console.log ("false");
> dfd.reject(data);// Reject our deferred object again with the data
> from the XHR response so that you could tailor an error message or
> something from it } });
>
> return dfd.promise;// Return the deferred's promise which is then'able.
> }
>
> // For demo purposes I have added a console message in each stage of
> the Async process and I have numbered them in the order they are
> written in code just to help illustrate the round about way Async
> happens c# are generated by code in checkPassword and m# are from the
> code surrounding the checkPassword call
>
> console.log("m1: before checkPassword()"); // NOTE: To use this method
> you would then do something like this...
> and since we used resolve and reject you could do this
> checkPassword(yourPass).then(logThemIn, kickThemOut);// What this
> means is if checkPassword success, pass its data to LogThemIn() else
> pass the failure data to kickThemOut()
> console.log("m2: after checkPassword()"); });
>
>
> --
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
>
> [hidden email]
> To unsubscribe, visit:
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
>
>

--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/ 

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-interest/attachments/20150302/b5d8a100/attachment-0001.htm 

------------------------------

Message: 3
Date: Mon, 2 Mar 2015 13:54:15 -0700 (MST)
From: zcurtis <[hidden email]>
Subject: Re: [Dojo-interest] Dijit styles when running two Dojo
        versions
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii

We have used nihilo for 1.5. For 1.10 we were leaning to claro. We have included both styles in the head.



--
View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Dijit-styles-when-running-two-Dojo-versions-tp4005451p4005492.html
Sent from the Dojo Toolkit mailing list archive at Nabble.com.


------------------------------

Message: 4
Date: Mon, 2 Mar 2015 16:09:57 -0500
From: Fred Duarte <[hidden email]>
Subject: Re: [Dojo-interest] pwCheck function in PasswordValidator
To: [hidden email]
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

unsuscribe

2015-03-02 14:25 GMT-05:00 Stephen Gevers <[hidden email]>:

> validateUserEntered is defined in the scope in which it was
> declared?that means it?s only defined inside the callback function for
> require.  Without knowing how you are trying to use the function, it?s
> difficult to say how to fix it.  The idea behind AMD is to limit the
> pollution of the global name space.  As Karl pointed out, it may not
> be the best idea to make the validateUserEntered function global.  
> However, it is easy to do?simply set window.validateUserEntered equal
> to your function inside the require callback.  However, there are still timing issues.
>  window.validateUserEnetered will not be defined until the require
> callback is executed.  And the callback won?t be executed until all of
> its dependencies have been loaded.  So it?s possible that the loader
> could still be trying to load ?dijit/registry? when you are wanting to
> use window.validateUserEntered.  It?s unlikely if you are waiting on
> user input before attempting to use the function that the loader
> wouldn?t have completed this task.  But it?s important to understand
> that some unknown amount of JavaScript code can be executed before the
> callback for this require is invoked.
>
> My best guess is that you have some JavaScript attached to a DOM
> element; for example, an onclick attribute on a button.  In this case,
> you are probably calling some function that has to be defined in the
> global namespace and that?s why you have gotten hung up on the nesting
> order of require / function def.  A better way might be to add some
> code to your require that uses dojo/on to attach a function to that
> button.  Since the function you would be attaching to handle the click
> event would be declared in the same scope as validateUserEntered, you
> wouldn?t need it to be global.
>
> Steve
>
> On Mar 2, 2015, at 12:54 PM, Harry Devine <[hidden email]> wrote:
>
> OK so I'm trying to understand what I've read and the examples given.  
> I have restructured my main js file to be similar to below:
>
> require([
>   "dijit/registry",
>   "dojo/dom",
>   "dojo/Deferred",
> ], function (registry, dom, Deferred){
>
>   function validateUserEntered() {
>     // check user entered here
>   }
>
>   // other functions here!
> });
>
> The problem I'm running into is I get an error stating that
> validateUserEntered is not defined.  This was the reason why I had the
> requires in each subfunction because doing it this was, as was
> suggested, wouldn't work and would give me these type of errors.  So
> how do I go about making this work?  I'm moving towards using Deferred
> on my async functions as was suggested, but in order to get to that
> function in my execution chain, I have to get this working first.
>
> Thanks!
> Harry
>
> ------------------------------
> *From: *"Karl Tiedt" <[hidden email]>
> *To: *[hidden email]
> *Sent: *Friday, February 27, 2015 7:50:55 PM
> *Subject: *Re: [Dojo-interest] pwCheck function in PasswordValidator
>
> Inline, because the wording on this response leads to so many possible
> misconceptions... And lets be honest, ambiguity is no help to
> comprehension. Harry, you would benefit greatly from looking over this
> link regarding Deferreds,
> http://dojotoolkit.org/documentation/tutorials/1.6/deferreds/
>
> -Karl Tiedt
>
> On Fri, Feb 27, 2015 at 12:16 PM, Stephen Gevers
> <[hidden email]
> > wrote:
>
>> Harry?You?re going to have to really think through what?s happening
>> at each line.  Notice that where you are returning the deferred is
>> inside the require call back function.  The checkPassword function has no return value.
>>
>
> Harry, this is the key problem with doing inline requires the way you
> were writing yours.
>
>
>>  Any return from the require call back function is ignored.
>>
>
> This is a very broad statement, if returns from require callbacks were
> ignored, AMD would never work... In this particular case, yes the
> return is ignored because we never exploit it.
>
>
>>  That?s the basis of what your problem is below.  But you seem to be
>> missing the async/deferred/promise concept all together.  And require
>> fits right into that async concept.  When you call checkPassword, the
>> callback function to required will not necessarily be called before
>> the call to checkPassword returns.
>>
>
> That is also an overly generalized statement, the require() callback
> *HAS* to complete before the checkPassword call "returns" assuming that "returns"
> means resolves... If by "returns" you mean "go to the next line of
> code to execute" then you are correct, the entirety of the
> checkPassword function will complete after that.
>
>
>>  Assuming you need your function to be globally defined, you would
>> rework your code to something like this:
>>
>
> Lets not assume this, because we would much rather teach GOOD practices.
>
>
>> require ([?dojo/request?, ?dojo/Deferred?], function (request,
>> Deferred) { window.checkPassword = function (password) { //
>> checkPassword body here?now you can return a Deferred, which will be
>> the result of calling the function, like you have below }; });
>>
>> Note that you can?t assume that the checkPassword function is
>> available yet!  If the next line of code after this require was to
>> call checkPassword, it would probably fail.
>>
>
> Aside from not promoting bad habits I have to say, HUH? You just
> defined checkPassword, it is absolutely safe to assume it is define...
> Maybe Harry isn't the only one who could use some practice in async
> behavior ;)
>
>
>>  For this reason, it would be better to define checkPassword as its
>> own AMD module.
>>
>
> Yup, you should definitely spend some time reviewing how this works as
> well... Breaking a single function out into it's own module does
> nothing to help improve your knowledge of "when its available", and
> unless this single function is worthy of its own module, you are just
> creating additional overhead.
>
> Here is a fully commented example of how I might right the code with
> some assumption that this is the executed JS file, not part of a
> modular piece of code (pastebin here: http://pastebin.com/1KiVHSuv )
>
> require([
> "dijit/registry",
> "dojo/request",
> "dojo/Deferred"
> ], function(registry, request, Deferred) {
>
> // NOTE: This is written as if it is not a module, but your main JS
> file that gets executed on page load...
> //   checkPassword would NOT be a global method so you would be calling
> it from some sibling code inside this file...
>
> function checkPassword(password) {
> var dfd = new Deferred(); // Create a deferred object that we will
> resolve at a later time
> console.log("c1: inside checkPassword()");
> request.post("checkPwd.php", { // Make XHR Post request to
> checkPwd.php
> handleAs: "json",
> data: {
> 'user': registry.byId("username").get("value"), // accessing .value
> isnt the best practice either, should almost always use the
> getter/setter
> 'pwd': password
> }
> }).then(function(data) { // Our XHR request completed... lets check
> the status and see if its a success or a failure
> console.log("c2: checkPassword() response", data); if (data.status ==
> "true") {// Success!
> console.log ("true");
> dfd.resolve(data); // Resolve our deferred object with the data from
> the XHR response incase we want to expose the results from the promise
> } else { // Failure!
> console.log ("false");
> dfd.reject(data); // Reject our deferred object again with the data
> from the XHR response so that you could tailor an error message or
> something from it } });
>
> return dfd.promise; // Return the deferred's promise which is then'able.
> }
>
> // For demo purposes I have added a console message in each stage of
> the Async process and I have numbered them in the order they are
> written in code just to help illustrate the round about way Async
> happens c# are generated by code in checkPassword and m# are from the
> code surrounding the checkPassword call
>
> console.log("m1: before checkPassword()"); // NOTE: To use this method
> you would then do something like this... and since we used resolve and
> reject you could do this checkPassword(yourPass).then(logThemIn,
> kickThemOut); // What this means is if checkPassword success, pass its
> data to LogThemIn() else pass the failure data to kickThemOut()
> console.log("m2: after checkPassword()"); });
>
>
>
> --
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
>
> [hidden email]
> To unsubscribe, visit:
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
> --
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
>
> [hidden email]
> To unsubscribe, visit:
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
>
>
> --
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
>
> [hidden email]
> To unsubscribe, visit:
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>
>


--
Regards,
Fred Duarte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-interest/attachments/20150302/a4d79503/attachment.htm 

------------------------------

________________
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest



End of Dojo-interest Digest, Vol 123, Issue 4
*********************************************
--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Dojo-interest Digest, Vol 123, Issue 4

Karl Tiedt
Help yourself please, every email contains the following instructions in the footer.


To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
or, via email, send a message with subject or body 'help' to
        [hidden email]

-Karl Tiedt


--
Dojo Toolkit: http://dojotoolkit.org/
Tutorials: http://dojotoolkit.org/documentation/

[hidden email]
To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest