|
Posted
over 17 years
ago
by
jmole
So this past week I've been working on a new data flow for our d-rails helpers in rails. I've implemented most of the dojo.fx functionality with this new flow, since it's a relatively small subset of functionality that would give me a pretty good
... [More]
idea if this was going to work well or not.
So let's start.
I ran across this page while researching dojo.fx, http://mzacher.de/sandbox/dojo.html , and while it's based on an older version of dojo, it gave me a good goal to work toward. Since the effects that he used on that page are unavailable in the current release of dojo, I did a bit of a stripped down version which I'll show you now.
First we'll look at a snippet of the view file:
<div id="fadeout" class="box" onclick='<%= fade_out "fadeout"%>'>
Fade out
</div>
<div id="highlight" class="box" onclick='<%= highlight "highlight", { :color => "#ffe761" }%>'>
Highlight
</div>
<div id="slideby" class="box" onclick='<%= slide_by "slideby", { :top => 50, :left => 22 }%>'>
Slide by (click again and again)
</div>
Pretty simple stuff here: 3 divs, each with a server-side generated onclick property. Each helper an element ID as it's first argument, and an options hash as its second.
Now lets look at how these helpers actually generate the code. Here's what the highlight helper looks like:
def highlight(element_id, options = {})
dojo_require("dojox.fx")
options[:node] = element_id
dojo_fx_play("dojox.fx.highlight", options)
end
Also pretty simple so far, we're just adding element_id to the hash under the name node, and calling dojo_require (to ensure that we load the library when the page is rendered) and dojo_fx_play (which actually generates the code required).
Now it gets a little more complicated. Lets look at what dojo_require and dojo_fx_play are actually doing:
def dojo_require(module_name)
@_dojo_requires ||= Set.new
module_name.each { |m| @_dojo_requires.add(m) }
end
def dojo_fx_play(function_name, *args)
dojo_function_call(function_name, *args) ".play();"
end
def dojo_function_call(function_name, *args)
out = function_name "("
args.each do |arg|
out << arg.to_json
out << (args.last == arg ? ")" : ",")
end
out
end
So dojo_fx_play just calls dojo_function_call with the method name and args list. dojo_function_call just directly converts the args list to json and outputs a javascript statement. The advantage to this is that dojo developers don't need to learn a new vernacular of options to use the methods they've always had.
dojo_require on the other hand, just keeps a list of which modules have been require'd so far in an instance variable to be used later.
I'm guessing that right about now you're wondering why I'm bothering to do any of this at all. dojo HAS a dojo.require function, and all I'm really doing is converting dojo functions to ruby syntax. The magic here comes in final helper, which isn't actually referenced in the view I showed you earlier.
def dojo_script_tag
out = ""
unless @_dojo_requires.nil?
@_dojo_requires.each do |req|
out << "dojo.require('#{req}');"
end
end
javascript_tag(out)
end
dojo_script_tag is (usually) called in the template instead of the views themselves. It makes sure you have all the dojo.require's that you need, and wraps them up in a script tag. The reason this is somewhat magical is because of the way rails handles templates.
If you have a template file, let's call it template.rhtml, it will look something like this:
<head>
<title>d-rails rocks!</title>
<%= javascript_include_tag :defaults %>
</head>
<body>
<%= render :partial => 'shared/header'%>
<%= yield %>
<%= render :partial => 'shared/footer'%>
<%= dojo_script_tag %>
</body>
The nice thing about templates is that they "compile" the files they include, before executing themselves. This means we can have lots of lots of helpers called from the header, footer, and main body, and not have to worry about keeping track of our dojo.require statements.
The code still felt a little incomplete though, so I wanted to try adding something else to make it a little more "dojo." Creating objects and running play() on them in the onclick handlers didn't seem like the best way to do this, so I came up with something a little bit different:
def dojo_fx_play(function_name, *args)
new_dojo_object(dojo_function_call(function_name, *args)) ".play();"
end
def new_dojo_object(constructor)
@_dojo_objects ||= []
name = @_dojo_objects.last.nil? ? "drails_object_000" : @_dojo_objects.last[:name].next
@_dojo_objects << {:name => name, :constructor => constructor}
name
end
def dojo_script_tag
out = ""
unless @_dojo_requires.nil?
@_dojo_requires.each do |req|
out << "dojo.require('#{req}');"
end
end
unless @_dojo_objects.nil?
@_dojo_objects.each do |obj|
out << "var #{obj[:name]} = #{obj[:constructor]};"
end
end
javascript_tag(out)
end
Now we can re-use the objects we've created. dojo_fx_play calls new_dojo_object, passing in what dojo_function_call returns, which adds it to the registry. new_dojo_object returns the name of the object after it's placed in the registry, which gets passed up the chain as "objectName.play()" for the onclick handlers. Finally, dojo_script_tag completes the circle by writing the object definitions in the same script tag as all the dojo.requires.
Of course there are several downfalls particular to this implementation.
Can't name your own javascript objects (yet)
I'm probably rewriting at least *some* functionality that rails already has. (dojo_function_call strikes me as very probable)
At the same time though, I think this is a good direction for things to be going. As always, I'd love to hear your thoughts, critiques, suggestions, etc. [Less]
|
|
Posted
over 17 years
ago
by
jbalogh
Demo
I'm pretty happy with how the drag and drop is turning out. I have a demo that you can play with, dragging dijit names to create real form objects. The basic functionality is in place, and I can iterate on this for the rest of the summer to
... [More]
turn it into something usable. If you're interested, you can check out the code with:
svn co http://svn.dojotoolkit.org/soc/2008/dndforms_jbalogh socPut the soc directory at the same level as dojo and dijit.
Duplicate source items
The sitepen blog was really helpful in working out my final dnd troubles. I was suffering from the problem outlined in the "Avoiding Duplicate Items" section: copyOnly is great for preventing item removal from a dojo.dnd.Source, but if you drop an item from that source onto itself, you get multiple copies of that item.
The fix for me was to create an around method that blocks a drop from the same source, along with setting the dnd manager's canDrop flag to false after every drop event.
Don't reinvent dojo
When I started creating dijits on the fly, I had a big array of objects, with the class, node type, and any extra parameters. For example, the object to create a TextBox with an input node:
{cls: dijit.form.TextBox, tag: "input", attrs: {type: "text"}}
First I would create the right type of dom node, add the correct attributes, and then pass in the node to create a new dijit. It was a lot of work, and completely unnecessary.
It turns out that each dijit does the right thing just given a div. The dijit._Templated classes disregard what you pass in, creating a new node according to the template. Other widgets apply their transformations to the div.
I'm learning to step back from the code, think about what I'm doing, and figure out which part of Dojo I'm trying to reimplement.
Where do we go from here?
I've had a bunch of encouraging comments so far (thanks!), and I was wondering how people are planning to use this project. What kind of app do you have, who will be creating the forms, how will the generated forms be used, etc.? I'll keep your comments in mind while I'm working on the rest of the project. [Less]
|
|
Posted
over 17 years
ago
by
jburke
Do you want Dojo code for an AIM-based text IM client that runs in a web page? Something that can play buddy sounds?
My employer, AOL, just open-sourced some Dojo modules that include a wrapper for the Web AIM API and UI widgets for user presence
... [More]
, the buddy list and sending and receiving instant messages (IMs).
The modules are open source versions of the modules used by AOL Webmail, so they have history in a real product. The modules are designed for Dojo 1.1 and above.
The source for the BSD-licensed modules is hosted on Google Code, at the aimdojo project. The first release, 1.0.0 is available for download. You can also use the code directly from the AOL Content Delivery Network (CDN), saving you some bandwidth. Here are two examples that use the AOL CDN:
Simple.html: Just shows the simplest usage of the modules, using aim.ImPanel with the default options.
ResizableFloatWithHoverCard.html: Shows how to use aim.ImPanel inside other dijit widgets that allow the buddy list to be dragged and resized. Also shows configuration options for the HoverCard (the info card that shows up as you hover over buddy names).
If you have comments or questions, please visit the aimdojo Google Group.
[Less]
|
|
Posted
over 17 years
ago
by
robertusj
Hi dojoers,
Last week is kind of researching week for me... since a lot of things came to me... From interview with Google Sydney (I am applying to work with Google) till "wet week" (people from NSW, AU should know this... Last week was raining all
... [More]
the time)... What have I been researching is what is the best data structure to support the 3d environment graphic? Especially for scene management (such as BSP, Octal, and soon) I also researching for best math calculation to boost the performance... Anyone know about camera management? At the moment, my camera is quite a bit suck... I would like to know more about n-DOF (Degree of Freedom)... If anyone has information about those, I would really appreciate if you can share a little bit to me... Ah! Lately, all sudden my head full of ideas... I just posted a project idea into forum and contributor mailing list... It is about including sound support into DOJO (If you interested go link)... [Less]
|
|
Posted
over 17 years
ago
by
osandi84
It hasn't been the most productive week for me. I've been exploring methods and ways to implement bullet chart. Also I'm doing some final touches on the candle plot.
Also I had lot of my time wasted bcoz I wanted to know how to put better blog posts
... [More]
:). It's really weird but actually I'm little unconfortable with blogs :(. Anyway I was able to get over with it to an extent in last few days.
If you are like me you would like this article http://betterexplained.com/articles/build-a-site-you-and-your-readers-wi....
Actually whole site was quite good. Anyway I'm back on track to develop bullet chart.. Hope to have something solid soon.. [Less]
|
|
Posted
over 17 years
ago
by
robertusj
Hi,
This week for my project is about user-usability. Thinking about how to make user uses the library easily... It is hard to think API for creating render object because there are many things that need to be covered (color, transformation, what
... [More]
shape n soon).
The creating object API is kind a bit hacky n hand waving (only createBox with a lot of assumption), it needs to be expanded for more flexibility. I also want to show small demonstration for what I have been doing so far, demonstrating with showing API is the best way to do, unfortunately, no API documentation at the moment... So what I can show to you at the moment is test page with sort of covering 60% API that I want to bring to user... Please go to the test page to see the demonstration. Note that, it is necessary to have Firefox 3.0 Beta 1 installed with proper Canvas3D extension (see the link in the page). Please give comment or suggestion... Thanks n have fun! [Less]
|
|
Posted
over 17 years
ago
by
propeller
This week I was working on a parser implementation and made some progress.
The parser I implemented consists of language definition part (where all tokens are defined), function definitions which process a particular token and a scanner that
... [More]
processes text, detects tokens and applies these functions.
To define a new token you need to add a new entry to tokens array in a language definition part, eg:
tokens: [
// token can be defined using "start" and "end" regexps
{ start: '\\[', end: '\\]',
mode: 'test',
token: dojox.markup.TestToken
},
// or, for simpler cases, it can be defined using "regex"
{ regex: '[-A-Za-z0-9_\\.\\, ]*',
mode: 'text',
token: dojox.markup.TextToken
},
...
]
For now scanner can process nested tokens and can process more complex cases, like token definitions with equal "start" and "end" or two tokens with equal "start" and different "end", etc
For now it can't:
process wrong nested tokens (eg {some [text}] )
it doesn't check the "allowed_children" property (which is used to define which tokens can be inside a particular token)
if anything goes wrong or it cant detect any token the error is generated
You can play with it here: soc week#02 dojox.markup tests.
Your comments are welcome. [Less]
|
|
Posted
over 17 years
ago
by
jmole
Ahh, it feels good to come back from a much-needed week long vacation following final exams. I know you all have been wondering what I've been up to, aside from enjoying my time in the sun and drinking margaritas. So for d-rails, the word of the
... [More]
week this week is testing.
Since we want to ensure d-rails is an easy drop in replacement, the behavior of the d-rails helper functions must be exactly the same as the existing helper functions which rely on prototype as their underlying library. The current rails distribution uses unit tests to test the helper functions, but these are only syntactic string comparisons which don't really test behavior in the same way that we need to test in d-rails. Here's an example of a test in prototype_helper_test.rb
def test_form_remote_tag_with_method
assert_dom_equal %(A BUNCH OF RANDOM HTML/JS THAT DRUPAL IS DELETING FOR ME BUT YOU DON'T NEED TO SEE IT TO GET THE POINT),
form_remote_tag(:update => "glass_of_beer", :url => { :action => :fast }, :html => { :method => :put })
end
As you can see, all this really does is compare the html/js spit out by the function call to a selected string. This type of testing is no doubt useful, as you want to ensure incremental changes you make don't cause your base test cases to fail. However, these tests are largely useless to us for testing that the behavior of the dojo helper overrides is equivalent to the default prototype implementation. What we really need is something that can compare the behavior of these in the browser.
I know a lot of you are yelling at the screen now, "Selenium! Selenium! Selenium!", which I agree is a good way to test real javascript behavior in real browsers. The problem I'm running into is not in selecting a test framework (I've pretty much settled on Selenium so far), but in actually getting the tests written.
I'll have to give some background on rails for you to appreciate the problems I'm encountering, so stick with me:
d-rails' current aim is to replace the built in prototype javascript helper methods in the ActionView::Helpers::PrototypeHelper module. A module in ruby is basically a mix-in for a class. To include a module in a class in ruby, you simply say include Qualified::ModuleName. In our current example, the prototype helper methods are instance methods applied to a controller in rails.
Controllers in rails process all incoming requests and spit out some output based on the request. Some data is shared between controllers and views, including the helper methods. So if we want to test this code in a real environment, we need to run these methods within the views or the controllers, and compare them. The problem comes when you want to have a d-rails prototype helper override method and a prototype helper method running in the same controller. (the reason we want something like this is so we can compare the two, side-by-side with selenium.)
I could go into a lot of details here, but the gist of it is that we can only have one module or the other loaded into the controller. More specifically, we can't switch modules in the midst of execution of a controller action (if we could, we could run link_to_remote with the default module, dynamically load the d-rails override module, the run link_to_remote again to get the dojo version of the function. Because of this, I've been trying to figure out a way selenium can observe the behavior of something on one page, load a new page and observe its behavior, then compare the two.
I know there is a lot of experience in the dev community with javascript testing tools, so maybe you guys can give me some advice.
There's also been something else that's bugging me about what we're doing now. I talked to a friend of mine, Brian Smith, who is part of the co-working space Downtown Cartel (which happens to be right down the street from me), and he was telling me about how javascript helpers in rails are evil. The article makes a lot of good points, and I'm not entirely sure that helpers really fit the dojo paradigm. (maybe some of you can let me know after reading that article)
I also ran across this post written about a month ago about writing your rails views in javascript, and it seemed to vibe well with the way I've seen dojo being used in practice. I'd really, really like to hear your thoughts on this. I don't know the best ways to use dojo in practice, but I'd like for rails developers to be doing it the same way as everyone else. The rails community is very receptive to Domain Specific Languages (DSLs), and writing a DSL to create views in ruby which leverages dojo and uses it in the way it's really meant to be used seems like a good idea. Any and all feedback is more than welcome. [Less]
|
|
Posted
over 17 years
ago
by
jbalogh
Working on the drag and drop form editor, I'm pulling in lots of modules: almost
everything in dijit.form, dojo.dnd (of course), and dijit.lang.functional &
dijit.lang.aspect because they're fun. Each module I require then pulls in
more
... [More]
files that it needs, so I was up to 131 web requests to load a single
page. The latency is acceptable on localhost, but it's absolutely terrible over
the network.
Pete Higgins has a couple of great screencasts over at dojocampus, but
it's kind of hard to refer back to a video, so here's my 5-minute build tutorial.
I'm assuming that your app code is in a directory next to dojo:
lib
|-- dijit
|-- dojo
|-- dojox
|-- mystuff
`-- utilFirst, find all the dojo modules that you're pulling in. cd to the root of
your app and run:
ack '^\s*(dojo.require[^;]*;)' -h --output='$1' | sort | uniq
This picks up all the dojo.require calls within your code and prints each one
out only once. The regex starts with \s* because I didn't want it finding
require's that I had commented out. I'm using ack, a replacement for grep that
uses perl regexes and is recursive by default. Using find and grep instead is
left as an exercise to the reader.
This prints the require's to the screen, but we want to put them all in a file for the
build system:
cat <<EOF > includes.js
dojo.provide("includes.js");
`ack '^\s*(dojo.require[^;]*;)' -h --output='$1' | sort | uniq`
EOF
I'm calling the file 'includes.js', and starting it with
dojo.provide("includes.js"); It looks like this:
dojo.provide("include.js");
dojo.require("dijit.form.Button");
dojo.require("dijit.form.CheckBox");
...
Source the includes file from your html page:
<script type="text/javascript" src="includes.js"></script>
This won't change anything right now, but it gets us prepared for later on.
Next we need to create a profile so the build system knows what to look for.
We'll call it my.profile.js:
dependencies = {
layers: [
{
name: "../mystuff/includes.js",
dependencies: [
"mystuff.includes"
]
}
],
prefixes: [
[ "dijit", "../dijit" ],
[ "dojox", "../dojox" ],
[ "mystuff", "../mystuff" ]
]
}
We create one layer, with the name ../mystuff/includes.js. The path is relative to
the dojo directory, so the build system will put the compressed file in the same
place the includes file currently resides.
The only dependency for this layer is includes.js, which we created earlier.
It's full of more dojo.require dependencies that the build system will trace
for us.
The prefixes array tells the build system what directories we want to include
in our build version. These directories will be copied over to the build site.
You need to list any modules that you use, even if they're not directly
referenced in a layer. See the dojobook for more info.
Now we're ready to start building. cd to util/buildscripts, where you'll
find a bunch of different build scripts. We want to use build.sh. The
incantation is
./build.sh profileFile=/path/to/my.profile.js action=release \
cssOptimize=comments optimize=shrinkSafe
Give profileFile the correct path to the profile created above, and leave the
rest of the parameters as is. They tell the build system to crank the
optimizations up to 11, removing comments, newlines, spaces, and turning on
shrinkSafe.
After a bit of churning, you'll have a shiny compressed version ready to stream
over the wires. My transfer size was cut by 56% (down to 9 requests), reducing
browser latency and making my app much more responsive.
[Less]
|
|
Posted
over 17 years
ago
by
propeller
The previous week was really hard for me. I had to do a lot of university stuff,
so unfortunately I had no chance to spend much time on my project.
But I did some research earlier though.
We had a conversation with my mentor about the best way of
... [More]
implementing a
generic parser. I wrote a simple implementation of multi-pass regex approach
(when you have a set of regexps and replacements for them and parser just
consecutively applies them to input text), which the original Markdown parser
uses.
And David implemented a simple lexer for MediaWiki syntax so we were able to
compare both approaches.
As a result I decided to use a lexer approach, because it is more flexible and
allows to simplify the language definition part (requires less code and regexps
are much simpler), so it would be easier to add a new language. With a lexer
approach it is good that you have an ability to operate with tokens and write
in token definition something like:
mode: "header",
allowed_children: [ "text", "bold", "link" ]it allows to create complex definitions but keep them simple and understandable.
The language definition could look something like:
tokens:
[ { start: '\n##', end: '##(?#\n)',
mode: "header",
allowed_children: [ "text", "bold", "link" ],
token: dojox.markup.HeaderToken
},
{ start: "[a-zA-Z0-9]", end: '[\\[\'\n]',
mode: "text",
token: dojox.markup.TextToken
},
// etc..
]With this approach we will have a standard set of tokens which know how to
convert themselves to html, these tokens would be used for all markup
languages (eg. BoldToken, ItalicToken, HeaderToken, LinkToken, ..). Of
course they can be redefined or extended if needed.
Currently I'm implementing a nested tokens processor. Will commit first code
soon.
If you have some questions or suggestions - please feel free to comment. [Less]
|
