ItsAllEasy

This could mean big things for AOP and Spring…

http://www.eweek.com/article2/0,1895,1855917,00.asp

Just chatting with nate about a few of his recent JSAN and Behaviour posts…his site was down when I tried to comment on them…so I’ll post the chat session here.

James: cool.
did you read this?
http://openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html
esp the section on namespaces.

nminshew: yes, that is where I got my examples and such.

James: I take from that page that you need to define and explicitly add to the namespace (so a use(’xml.Blah’) wont do anything if xml/Blah.js doesn’t actually have a blah class in an xml namespace.
also about the Behaviour thing…i think you need to be careful about how you’ve done it…I would actually consider it flawed…just by chance that it works. what you’ve told it to register is a hash that IS the function…when behaviour iterates over that hash it is adding rules for the items you’ve defined inside the function…but also properties of the function itself. You’d be much better off by defining the hash directly (as the docs do).

nminshew: Yeah, I guess it wasn’t exactly as I thought it was. That kind of sucks actually, because if you have a complex heirarchy, that can get pretty complicated.
I got that [Behaviour] example straight from the docs. I used their example when I wrote my first app.

James: I’ve never seen that example anywhere. send me a link.

nminshew: Well their site has moved and changed since I first went there, I don’t know if I can find it again, but I’ll try.
I pretty much copied and pasted it though. the window.onload and everything.
Sent at 8:54 AM on Tuesday

nminshew: I can’t find it, but I didn’t come up with the function names and such and wouldn’t of thought to do it that way if it wasn’t for the example.
Also, what is you problem with putting the rules in a function and passing it to the register method?

James: anyway it is was a bad example. I’d change the code to do as it shows on the docs now.

nminshew: In my example, I should have had () after defineRules.

James: I don’t have a problem with that…but exactly…the way you had it confused me and that was the ‘does this work’ question came from…you were passing a reference to the function not calling the function and passing what was returned….thought it was a typo at first…but the function did not have a return statement.
To make it work such that you can (as you have already changed it to do) call the method is like so:

function defineRules() {
var rules = {
‘a.popup’ : function (element) {
var popupLocation = element.href;
element.onclick = function () {
window.open(popupLocation);
}
element.href = ‘javascript:void(0);’;
}
};
return rules;
}

OR

function defineRules() {
return {
‘a.popup’ : function (element) {
var popupLocation = element.href;
element.onclick = function () {
window.open(popupLocation);
}
element.href = ‘javascript:void(0);’;
}
};
}

nminshew: Yeah yeah, I know, that was another typo I just fixed.
Here’s an example of someone else doing it this way: http://javascript.about.com/library/blonload.htm

James: I’d really recommend that you re-consider the onload thing. a lot of scripts add onload events (in a non-destructive, portable way)….it really makes it easy for me to just take advantage of some lib or module that does so…I dont’ have to know that if i use a module, i’ll need to plug in some boiler plate onload event that will call it…it could get pretty hairy if i’ve got a lot of modules I’m using that have some work to do when the page loads.
that’s [the link] gonna blow away any registered onload events.

nminshew: Well if you do it statically, don’t you run the risk of it executing before all the elements are loaded on the page?

James: I”M not saying do it statically…I’m saying register an event handler (all browsers support what are effectively event listeners…just in different ways). I’m saying register a listener for the onload event on the window.

nminshew: do you have an example of the way you are talking about?

James: yes, i sent the link to you via email yesterday [http://www.scottandrew.com/weblog/articles/cbs-events]. Its what I’ve been using here.
from my code:
addEvent(window, ‘load’, initWidgets);

that adds an ‘onload’ listener to the window object…so when onload occurs, the initWidgets method is called.
(addEvent is the function written by the guy in that article)…actually I somehow found a version that doesn’t have the useCapture stuff…written by a different guy…looks mostly the same just minus that useCapture boolean

nminshew: k, thanks. I’ve just never known a better way of doing it.

James: which is why i thought you’d like to know.

nminshew: thanks.
do you have the example without the useCapture?

James: funny…it’s on the unobtrusive article:
http://www.onlinetools.org/articles/unobtrusivejavascript/chapter4.html

I’ve made some progress on the TableModel. Currently it supports (from least to most interesting):
getRows - returns the rows (data-only) for the TableModel.
getColumns - returns the columns for the TableModel (currently just the TH objects that make up the column headings)
getDataModel - returns the data model that the table is displaying data for. Currently just a 2-d array of the data rows’ (via getRows) content.

It supports defining the table with the mark-up and can handle simple tables, tables with a header row and tables with a THEAD.

Should start getting interesting soon…

I’m putting together a kind of JavaScript TableModel object to facilitate some things on a project at work. So, this is my cram session for it. You can see the ideas change and clarify as it goes.

TableModel is the data.
TableView binds to and inspects the TableModel to determine how/what to display
BeanBackedTableModel has a data object that serves as the backing for the actual cell data in the table.
However, TableModel is PRIMARILY the model for the actual TABLE. So, it holds the state for the TABLE entity. The fact that part of that state may come from an underlying data object is secondary.
TableView must be able to (potentially given the type of TableModel) reconstruct the model only from the (potentially very basic) view representation. So, for example, on an initial page load if there is data in the table by default, that data should be extracted/scraped from the view to initialize/construct the inital model. This feature may also be implemented as an entirely separate object…a TableModelInitializer perhaps.
In the latter case, the TableView that eventually is bound to the same table must be made aware of the inital state (this is why it may make sense for the 2 things to be on the same object.

DataModel always holds all of the data for the table (even data for cols and rows not displayed) in insertion order. It will always be an array. The array may contain: arrays, hashes, or objects. The default data model will simply be a 2d array of strings. When modifying a table (adding/removing rows) the DataModel is what is manipulated. When modified it will fire a modified event…the table model will be nofitied of it and will modify its rows collection and fire a modified event of its own with the new DOMRow as a property on the event (which will travel up the chain to the JSTable object, potentially being further modified/behavior-ified along the way). The JSTable will then decide it is time to update the view (depending on the type of event (added/removed/updated) and will affect the change to the underlying dom table.

Ok…good for an up-front design/cram session. Now go do some TFD keeping this in mind as something to work toward.