tw.dojo.DojoButton error

[dakila]

Hello,

While trying to recreate the 'Hello World' example from the dojo book
using widgets, I think I found a bug.
The template in DojoButton widget should use <button> instead of <div>
Can someone confirm this?
I can create a ticket in http://code.google.com/p/twtools/issues if
there is a need.

old:
In [1]: from tw.dojo import DojoButton

In [2]: d = DojoButton(title='title')

In [3]: d.render()
Out[3]: u'<div id="" dojoType="dijit.form.Button" onClick="">title</
div>'

new:
In [1]: from tw.dojo import DojoButton

In [2]: d = DojoButton(title='title')

In [3]: d.render()
Out[3]: u'<button id="" dojoType="dijit.form.Button" onClick="">title</
button>'


Here's the diff

Index: dojo.py
===================================================================
--- dojo.py (revision 255)
+++ dojo.py (working copy)
@@ -130,7 +130,7 @@
onClick = ''
title = ''
params = {'onClick':'the onClick method','title':'Button title'}
- template = "<div id='${id}' dojoType='${dojoType}' onClick='$
{onClick}'>${title}</div>"
+ template = "<button id='${id}' dojoType='${dojoType}' onClick='$
{onClick}'>${title}</button>"


class DojoInlineEditFarm(DojoBase):
@@ -273,4 +273,4 @@
others=[]
out='[{cells:'+cols_str+'}]'
print out
- return out
\ No newline at end of file
+ return out

[michele]

Hi dakila,
in most dojo widgets you can use either the native tag (e.g. button)
or div tag,
while using div tag could be useful for generic widget creation, for
example i could create a for loop on a div applying on each div
a different dojoType, the usage of native tag (button) could be useful
when javascript is disabled as the dojo button would be rendered
correctly as a normal button.
For your reference you could have a look at:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Button.html
where dojo people use both divs and buttons.

If divs are preferred I'll change the template code.
I'll add the newline at end of file.

Thank you for using tw.dojo and spotting errors and improvements.
If you want to help developing tw.dojo any help is welcome.
Dojo inline edit box is very interesting (http://
archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/
test_InlineEditBox.html),
my widget implementation tries to automate the editing process and if
someone is interested i wrote some turbogears/sqlalchemy code
to automate create,read,update,delete,list via json of sqalchemy
objects.

Michele.

[dakila]

Hi Michele,

Thanks a lot for taking time explain regarding my question :)
I tried your inline edit web app and it is really cool! Just an
observation, once you get to use it, up and down arrow keys don't
respond in order to navigate the rest of the page.

Since Im just starting out with dojo + tg2 combo, I am very much
interested in your automated CRUD stuff.

One more thing, any thoughts on why the __init__ method in class
DojoBase is commented?

Best regards,
Dakila

On May 27, 6:38 pm, michele <michele.berto...@gmail.com> wrote:
> Hi dakila,
> in most dojo widgets you can use either the native tag (e.g. button)
> or div tag,
> while using div tag could be useful for generic widget creation, for
> example i could create a for loop on a div applying on each div
> a different dojoType, the usage of native tag (button) could be useful
> when javascript is disabled as the dojo button would be rendered
> correctly as a normal button.

> For your reference you could have a look at:http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/t...

[michele]

Di Dakila,
the link I posted is a dojo test, not mine...
I just did some js/python code to automate this process with
toscawidgets.
I'll post in next days a demo of the tw.dojo/json combo.
The __init__ method in dojobase is commented out because... i didn't
get it
to work properly. I'm not really into some inner workings of
ToscaWidgets,
especially JSSource and js_function calls.
I'll ask some help to someone more experienced.
What I wanted to do was to automate dojo.require calls for instanced
widgets.

Regards,
Michele.

[Alberto Valverde]

>
> Di Dakila,
> the link I posted is a dojo test, not mine...
> I just did some js/python code to automate this process with
> toscawidgets.
> I'll post in next days a demo of the tw.dojo/json combo.
> The __init__ method in dojobase is commented out because... i didn't
> get it
> to work properly. I'm not really into some inner workings of
> ToscaWidgets,
> especially JSSource and js_function calls.

I'll take note of this for a tutorial/doc. I've seen some non-optimal
usage of this in the wild (no-one's fault but mine for lack of docs!) so I
guess it's about time to properly document it.

> I'll ask some help to someone more experienced.
> What I wanted to do was to automate dojo.require calls for instanced
> widgets.

This is doable with a pattern similar to how js calls are injected in the
page. Basically add_call [1] appends the JS string to a
RequestLocalDescriptor [2] (a descriptor that stores it's attribute in
request-local storage so its lieftime is bound to the duration of a
request) which is later picked up by a JSSource subclass [3] that renders
them.

I can take a chip at implementing it and help out with tw.dojo in general
since I'll most probably be using it for my SoC project :)

Alberto

[1] http://beta.toscawidgets.org/trac/tw/browser/tw/core/base.py#L453
[2] http://beta.toscawidgets.org/trac/tw/browser/tw/core/base.py#L177
[3] http://beta.toscawidgets.org/trac/tw/browser/tw/core/resources.py#L371

[michele]

Thank you Alberto,

> I'll take note of this for a tutorial/doc. I've seen some non-optimal
> usage of this in the wild (no-one's fault but mine for lack of docs!) so I
> guess it's about time to properly document it.

in the meantime I'll read the code more deeply.

> This is doable with a pattern similar to how js calls are injected in the
> page. Basically add_call [1] appends the JS string to a
> RequestLocalDescriptor [2] (a descriptor that stores it's attribute in
> request-local storage so its lieftime is bound to the duration of a
> request) which is later picked up by a JSSource subclass [3] that renders
> them.
>
> I can take a chip at implementing it and help out with tw.dojo in general
> since I'll most probably be using it for my SoC project :)

only a question: add_call injects code always on bodybottom or may I
inject on bodytop
or head?
Asking this because often i need to place a js call after widget (js
call may refer to it), but
in my very specific problem I need to add 'dojo.require' call before
widgets to have them correctly
initialised.

> Alberto

Thank you,
Michele.

[Alberto Valverde]

michele wrote:
> (...)

> only a question: add_call injects code always on bodybottom or may I
> inject on bodytop
> or head?
>

Only at bodybottom ATM

> Asking this because often i need to place a js call after widget (js
> call may refer to it), but
> in my very specific problem I need to add 'dojo.require' call before
> widgets to have them correctly
> initialised.
>

I was thinking of implementing something similar to the add_call()
mechanism to insert the dojo.require calls at <head> but your question
gave me a better idea. add_call could grow a "location" parameter to
specify where in the page the code should be injected. This will be more
useful since it won't be limited to tw.dojo. I've opened a ticket [1]
for it.

BTW, I just imported tw.dojo's SVN repository into toscawidgets.org and
opened up a Trac as we talked about. If you don't have an account
already please create one and send me your username so I can give you
"push" access to the repository and admin rights on the Trac. Is there
anyone else who needs "push" access to this repo?

Alberto

[1] http://beta.toscawidgets.org/trac/tw/ticket/8

[Alberto Valverde]

michele wrote:
> Thank you Alberto,
>
>
>> I'll take note of this for a tutorial/doc. I've seen some non-optimal
>> usage of this in the wild (no-one's fault but mine for lack of docs!) so I
>> guess it's about time to properly document it.
>>
>
> in the meantime I'll read the code more deeply.
>
>
>> This is doable with a pattern similar to how js calls are injected in the
>> page. Basically add_call [1] appends the JS string to a
>> RequestLocalDescriptor [2] (a descriptor that stores it's attribute in
>> request-local storage so its lieftime is bound to the duration of a
>> request) which is later picked up by a JSSource subclass [3] that renders
>> them.
>>
>> I can take a chip at implementing it and help out with tw.dojo in general
>> since I'll most probably be using it for my SoC project :)
>>
>
> only a question: add_call injects code always on bodybottom or may I
> inject on bodytop
> or head?
> Asking this because often i need to place a js call after widget (js
> call may refer to it), but
> in my very specific problem I need to add 'dojo.require' call before
> widgets to have them correctly
> initialised.
>

Michele, add_call() supports a location parameter since 0.9. To add a
dojo.require call at the head you can do:

def update_params(self, d):
super(...).update_params(d)
dojo_require = js_function('dojo.require')
require = ['dojo.foo', 'dojo.mojo']
for r in require:
self.add_call(dojo.require(r), 'head')

BTW. The class attribute "include_dynamic_js_calls" is no longer needed.

Alberto

[Sanjiv]

>
> Michele, add_call() supports a location parameter since 0.9. To add a
> dojo.require call at the head you can do:
>
> def update_params(self, d):
>     super(...).update_params(d)
>     dojo_require = js_function('dojo.require')
>     require = ['dojo.foo', 'dojo.mojo']
>     for r in require:
>         self.add_call(dojo.require(r), 'head')

Excellent. I think this has been limiting my use of js_functions /
callbacks so far

>
> BTW. The class attribute "include_dynamic_js_calls" is no longer needed.
>

Awesome, it surely had caused me a few headaches initially :)

Regards
Sanjiv

[michele]

> Michele, add_call() supports a location parameter since 0.9. To add a
> dojo.require call at the head you can do:

Wonderful Alberto,
thank you very much.

now I have just another question...

> def update_params(self, d):
>     super(...).update_params(d)
>     dojo_require = js_function('dojo.require')
>     require = ['dojo.foo', 'dojo.mojo']
>     for r in require:
>         self.add_call(dojo.require(r), 'head')

add_call() in update_params gets called at every display, right?
If I put 4 widgets of the same type in my page, I'll get 4 identical
dojo.require calls?
If I place add_call() in __init__() does it work?

Thank you for the good job,
Michele.
P.S.: Yesterday I corrected a bug spotted by dakila and committed to
both google code svn and toscawidgets mercurial.
Is the idea to move the all tw.tools to mercurial at
beta.toscawidgets.org? Should I continue to commit on both
repositories?

[Alberto Valverde]

michele wrote:
>
>> Michele, add_call() supports a location parameter since 0.9. To add a
>> dojo.require call at the head you can do:
>>
> Wonderful Alberto,
> thank you very much.
>
> now I have just another question...
>
>
>> def update_params(self, d):
>> super(...).update_params(d)
>> dojo_require = js_function('dojo.require')
>> require = ['dojo.foo', 'dojo.mojo']
>> for r in require:
>> self.add_call(dojo.require(r), 'head')
>>
>
> add_call() in update_params gets called at every display, right?
>

Yes.

> If I put 4 widgets of the same type in my page, I'll get 4 identical
> dojo.require calls?
>

If you're not careful then yes.

> If I place add_call() in __init__() does it work?
>

Yes, but you'll have the same duplicated dojo.require calls if the
widget is instantiated multiple times and each instance displayed.

I'll recommend for this case to jave just one DojoRequireCalls singleton
which has a "require" attribute with a RequestLocalDescriptor which
keeps attributes in request-local storage so they can be changed
dynamically. Something like this (simplified)

from tw.api import RequestLocalDescriptor, JSDynamicFunctionCalls

class DojoRequireCalls(JSDynamicFunctionCalls):
location = "head"
javascript = [dojo_base]
# This is an attribute which can hold requirements in a request-local
# set. anything added here will only be visible in the current request
_require = RequestLocalDescriptoror("dojo_require_calls", default=set)
def call_getter(self):
# return dojo.require calls. This is called by the superclass
return map(js_function('dojo.require'), self._require)
def require(self, requirement):
# Called by dojo widgets which want to inject a requirement
self._require.add(requirement)
# Inject ourselves into the page fisrt time we're called (we can
inject
# ourselves many times but only will get rendered once
self.inject()

# instatniate ourselves as a module-level singleton
dojo_require = DojoRequire("dojo_require")

Now, any widget that wants to append a 'dojo.require' call can do:

def update_params(self, d):
super(....)...
# note that you have to do this on every request, ie, in update_params
dojo_require.require("dojo.dixit.fooo")

If you take a look at the code in resources.py which handles add_call
injections you'll notice that this is more or less the same pattern...

> Thank you for the good job,
> Michele.
> P.S.: Yesterday I corrected a bug spotted by dakila and committed to
> both google code svn and toscawidgets mercurial.
> Is the idea to move the all tw.tools to mercurial at
> beta.toscawidgets.org? Should I continue to commit on both
> repositories?
>

No please, else we'll go nuts ;). Just tw.org.

Alberto

[michele]

SImple and elegant, pythonic in one word, I'll go for it.

> No please, else we'll go nuts ;). Just tw.org.

It's better also for me...
> Alberto
Thank you,
Michele

[michele]

Alberto,
i just committed the tw.dojo code to inject dojo.require methods.
Your way worked perfectly.
In tw.core.resources in __all__ is missing "JSDynamicFunctionCalls"
so I imported directly.

Thank you,
Michele.