JooseX.DOMBinding.JQuery - Test Coverage, Features, etc.

[Mike Walker]

Hi Malte & All,

What's the state of JooseX.DOMBinding.JQuery?

It's certainly functional, but it's very minimal. It doesn't have any
unit tests, and the only application which uses it in subversion is the
Sticky Notes demo app.

I'm currently using it, with a few minor modifications, for an
application at my dayjob. It certainly has a lot of potential - for a
broad set of features and for supporting a generic API to allow other
DOM-manipulation libraries.

I guess my main concerns right now, or my real world needs, are around
the usability of it. For example, I had to add support for a "filter"
property that massages the data between Joose objects & DOM elements.
That sounds like something that's best implemented as an overall design,
not just tacked on.

I'm interested to know your thoughts on the future of JooseX.DOMBinding.

Thanks & Cheers,
Mike

[Malte Ubl]

Hey,

I agree that DOMBinding has great potential.

I tried to refactor it a couple weeks ago but then reverted the
changes and updated to your commits a couple days ago, because I
didn't get anywhere. There is something fishy about the design. I
always keep forgetting how it works. That doesn't feel good :)

It'd be great if you continue to work on it. I'm planning to use it at
a project at my dayjob, too (airline website, that does realtime
updates of pricing information based on user choices).

It'd be great if you would build a better foundation for that work.
My plans are in particular
- Improve DOMBinding to work with pretty much every control available on the web
- Integrate an input validation framework based on types
- Implement localization for types
- Implement an internationalization framework based on Joose

They are going to materialize some time in november, but I might have
to work in a branch until december and I might have a hard time to
reintegrate with something that is generic enough for Joose.

Bye
Malte

[Mike Walker]

The #1 rough spot for me was integrating the bindings with my
fine-grained types. That's what really pushed me to add nullable support
to attributes (I still need to check that in... how many votes did your
vote count for? :P )

I agree with you that the current implementation is a little off. It's a
great example of how quick & easy it is to add capabilities to Joose,
but that's what it feels like - an example.

I haven't given it much thought beyond what I've had to overcome to get
my stuff working, but your list seems like a great starting point. I'll
post my thoughts to the list as they get more concrete, here are a few:

- JooseX.DOMBinding
- An API that's precise enough for detailed use, but generic
enough for many third-party modules to fit under (bind element,
bind object, bind property, one-way and two-way synchronization)
- JooseX.DOMBinding.Data
- A place/way to centralize policies for getting text-based
DOM data into Joose objects (using as much of the type system
as possible)
- A simple way to associate error messages with policy/type
violations.
- Re-worked TypeConstraint error messages. Or removed & refactored
Type error handling. I could see each Type listing out named
constraints along with error messages for each locale. Of course
most types would only have one error message: "Value not a Foo",
so maybe part of a type definition could just be an enumeration
of "error_name => locale => message" triplets.

It's fortuitous though, the next application up on my plate, which will
be very similar to the one I'm wrapping up now, will have to be heavily
internationalized, as we've got to provide the entire thing in Spanish
as well :)

Cheers,
Mike

[Mike Walker]

Heh,

Every day I come across more needs for DOMBinding - it's nice seeing
real-world needs. Here's one that I'm dealing with right now:

Radio Buttons!

How can Joose objects be bound to and interact effectively with radio
buttons, select options, and checkboxes?

Does this bring up issues of Parameterized Types? I can certainly smell
Lists of values and Maps of values here ...

Pardon my ramblings on the list. I'm partly using the mailing list as a
record of my thoughts, but if anyone has any
ideas/experience/frustration with these I'd love to hear them.

Cheers,
Mike

[Malte Ubl]

Hey,

On Tue, Oct 28, 2008 at 4:47 PM, Mike Walker
<mike-...@napkindrawing.com> wrote:
>
> Heh,
>
> Every day I come across more needs for DOMBinding - it's nice seeing
> real-world needs. Here's one that I'm dealing with right now:
>
> Radio Buttons!
>
> How can Joose objects be bound to and interact effectively with radio
> buttons, select options, and checkboxes?

I might be wrong here. My impression was that from the jQuery point of
view a radio button and a select box are the same thing.

$("#radio").val("aValue")

> Does this bring up issues of Parameterized Types? I can certainly smell
> Lists of values and Maps of values here ...

I don't know whether we need to have enum types for selects and
radios. Both "guarantee" the range of valid values to the selectable
values.

This is even more true if the values of one select box are depended
upon another in which case valid values changes dynamically.

> Pardon my ramblings on the list. I'm partly using the mailing list as a
> record of my thoughts, but if anyone has any
> ideas/experience/frustration with these I'd love to hear them.

Thanks for the input. As I said I am very much interested in the
development of the DOMBindings and will start adding features as soon
as I start development of my next work project.

Bye
Malte

[Malte Ubl]

On Tue, Oct 28, 2008 at 12:23 AM, Mike Walker
<mike-...@napkindrawing.com> wrote:
>
> The #1 rough spot for me was integrating the bindings with my
> fine-grained types. That's what really pushed me to add nullable support
> to attributes (I still need to check that in... how many votes did your
> vote count for? :P )

Go for nullable :) I'd still be interested when you'd get a null value
with respect to DOMBinding?

[Jeremy Wall]

It occurs to me that perhaps a type we might want to have in the Joose type Hierarchy would be DOMElements.  A good way to bind a Joose Class to a Dom element would be as an attribute of the class. This perhaps should be in a seperate optional set of types but we could build a whole hierarchy of them there.

[Malte Ubl]

I keep thinking whether DOMBinding should look like this:

Class("CarConfiguration", {
has: {
tire: {
bind: ".tireSelector"
}
}
})

I don't think we should have anything in Joose that knows about the
DOM. Leave that to jQuery (etc) and we do the fun stuff :)

Generic widget types with a DOM implementation might be another story.
I'm not sure.

Malte

[Jeremy Wall]

I was thinking DOM TypeConstraints would probably live under the JooseX namespace so they wouldn't be part of Joose internal but they would be useful enough I think to bundle in the Joose distribution.

[Malte Ubl]

Hey,

we can definetely build such a hierarchy if needed. My current
thinking is that these should not go along DOMElements but rather
along jQuery interfaces.

ThingsRespondingToVal
ThingsRespondingToHtml
etc.

Anyway, such a tool should be build around real world needs and cant
be designed up front. So, I guess, we'll just do it :)

Malte

[Mike Walker]

Hi All,

Keeping in mind the limitations of jQuery (val vs. html) is important,
but I was also thinking about what a ... forgive me .... a Joose
implementation of DOM objects would look like, and if that would be
helpful...

JooseX.DOM.InputText, JooseX.DOM.RadioButton,
JooseX.DOM.RadioButtonGroup, JooseX.DOM.Div

Another thing that might be a nice side-effect of this is the ability to
create a separate class to manage the DOM aspects of another class. I'd
really like that for the sake of unit testing business logic (and even
working server-side in something like Rhino or Helma)... it's so nice to
just call foo.setBar("baz") and not have to fake out a bunch of elements
to get your tests to work. But in the browser instead of saying:

var foo = new MyApp.Foo();

You could say:

var foo = new MyApp.DOM.Foo();

Which would wrap all the functionality & business logic of MyApp.Foo
with the DOM input/output management specified in MyApp.DOM.Foo.

That would allow fine-grained interaction with DOM elements and groups
of elements. I foresee the need to deal with groups of elements given
select/option and radio buttons having multiple actual elements that are
logically bound together. If implemented properly this would also allow
a neat logical binding of unrelated elements, for example Malte's
mention of select boxes that fire events in other select boxes.

But yes, I think we'll need to see what would work in the real world,
and what would serve us best, I'm looking forward to it :)