openajaxallianc-contributors — For developers who are official Contributors to the OpenAjax Alliance project

Re: [OpenAjax-Contributors] HUB: Hub 1.0 & 1.1 interdependencies

[Javier H P. <ped...@us...>]

Frederik De Keukelaere  wrote on 05/19/2008 11:00:09 PM:

> That sure sounds reasonable. But isn't Hub 1.1 a superset of Hub 1.
> 0? In that case by implementing Hub 1.1 wouldn't you implement Hub 
> 1.0 automatically anyway?

Yes, Hub 1.1 is a superset of Hub 1.0.  But there is no current 
requirement that (for example) they both be provided by the same JS file. 
In fact, during the discussion (at the face-to-face, I believe), it was 
assumed that there could be one file that provided Hub 1.0 and another 
that extended that to support Hub 1.1.

So the question is whether we want to allow such a thing and to allow 
mixing-and-matching of different 1.0/1.1 implementations.

> If so, wither or not you reuse the 
> OpenAjax Hub 1.0 code or some other implementation of Hub 1.0 would 
> not really be a relevant question since the developer would deliver 
> a Hub 1.1 compliant piece of software. 
> 
> In other words, I was under the assumption that what you stated as a
> solution would be the chosen path anyway. 

So, whereas you assume what I propose as a solution, others may see it 
differently.  I just want to make sure that we put this down in writing, 
so no one has to assume...


Javier H Pedemonte

[OpenAjax-Contributors] HUB: more fine-grained pub/sub manager callbacks?

[Javier H P. <ped...@us...>]

Currently, the Hub 1.1 specification allows to each of a publish and 
subscribe callback on each managed hub instance (
http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Specification_Managed_Hub_APIs#OpenAjax.hub.createManagedHub.28.7B.5BpubCallback:function.5D.2C_.5BsubCallback:function.5D.7D.29
).  These callbacks are called for each and every subscribe and publish 
event that goes through the hub instance.

The callbacks are useful in case the developer wants to impose a 
connection policy, such as 1-to-1 connections between widgets.

One issue with this approach is that it forces a developer using the Hub 
to put all of their logic into one callback event.  If the logic is 
static, then it shouldn't be too hard to write the callback code. However, 
if the widgets on the page are handled dynamically, then the developer 
would need to write code to pull in the connection policy dynamically, 
depending on the widgets on the page and what connections exist between 
the widgets.  This can be difficult.

Another approach would be to define more fine-grained pub/sub callbacks. 
The developer would call hubHandle.addPublishManager() or 
hubHandle.addSubscribeManager(), along the lines of adding an event 
listener.  The two methods would also support a "filtering" method, such 
that the developer could define when the callback is called, depending on 
the value of the topic name, subscriber ID and/or publisher ID.

For example, let's say there are three calendar widgets ("calendarA", 
"calendarB", "calendarC") which publish on topic "date", and there are 
three date listeners ("dateListener1", "dateListener2", "dateListener3") 
which subscribe on topic "date".  The developer wants to impose a policy 
such that (1) "dateListener1" only accepts "date" events from "calendarB"; 
and (2) "calendarA" has a 1-to-1 connection with "dateListener3" on the 
"date" topic.

The code for the existing Hub spec would look something like this:

        publishManager = function( topic, message, publisherID, 
subscriberID )
        {
                if ( subscriberID == "dateListener1" && topic == "date" ) 
{
                        return publisherID == "calendarB";
                }
                if ( topic == "date" ) {
                        if ( publisherID == "calendarA" ) {
                                return subscriberID == "dateListener3";
                        }
                        if ( subscriberID == "dateListener3" ) {
                                return publisherID == "calendarA";
                        }
                }
                /* .... */
        }

For my proposal, the code might look like this:

        var pubCB1 = hubHandle.addPublishManager(
                function(topic, message, publisherID, subscriberID) {
                        return publisherID == "calendarB";
                },
                {subscriberID: "dateListener1", topic: "date"} /*filter*/
        );
        var pubCB2 = hubHandle.addPublishManager(
                function(topic, message, publisherID, subscriberID) {
                        if ( publisherID == "calendarA" ) {
                                return subscriberID == "dateListener3";
                        }
                        if ( subscriberID == "dateListener3" ) {
                                return publisherID == "calendarA";
                        }
                },
                {topic: "date"} /*filter*/
        );

I think it makes it easier to break up the code like this.  Also, these 
pub/sub callbacks can be created/destroyed on the fly, as the connections 
in the mashup app are created/destroyed.

This could be made even more powerful by allowing wildcards in any of the 
filters.

The main drawback to this approach is that it adds complexity to the Hub 
code (in particular, wildcard support), which in turn means a larger code 
base.  Also, having many of these callbacks could impact performance of 
the Hub.

What does everyone think of this proposla?


Javier H Pedemonte

Re: [OpenAjax-Contributors] HUB: Hub 1.0 & 1.1 interdependencies

[Frederik De K. <EB...@jp...>]

Hi Javier,

That sure sounds reasonable. But isn't Hub 1.1 a superset of Hub 1.0? In 
that case by implementing Hub 1.1 wouldn't you implement Hub 1.0 
automatically anyway? If so, wither or not you reuse the OpenAjax Hub 1.0 
code or some other implementation of Hub 1.0 would not really be a 
relevant question since the developer would deliver a Hub 1.1 compliant 
piece of software.

In other words, I was under the assumption that what you stated as a 
solution would be the chosen path anyway.

-Fred
---
Frederik De Keukelaere, Ph.D. (フレデリク　デクゥーケラーレ)
Researcher
IBM Research, Tokyo Research Laboratory


ope...@li... wrote on 
20/05/2008 12:28:04:

> [image removed] 
> 
> [OpenAjax-Contributors] HUB: Hub 1.0 & 1.1 interdependencies
> 
> Javier H Pedemonte 
> 
> to:
> 
> openajaxallianc-contributors
> 
> 20/05/08 12:29
> 
> Sent by:
> 
> ope...@li...
> 
> 
> A while back, someone brought up the point that the current 
> reference implementation of Hub 1.1 depends on the Hub 1.0 code and 
> makes use of internal methods (in particular, the methods that 
> handle the subscription tree and wildcard support).  The issue is 
> that because of this interdependency, the Hub 1.1 impl (OpenAjax-
> mashup.js) cannot be used with another Hub 1.0 impl. 
> 
> One suggested solution was to standardize the Hub 1.0 internal 
> methods and make them available such that any Hub 1.1 impl can work 
> with any other Hub 1.0 impl. 
> 
> But this isn't ideal, since we would have to reopen discussion on 
> the Hub 1.0 spec, for what are mainly implementation details. 
> 
> I think a better solution would be to stipulate that any Hub 1.1 
> impl also include (or be matched with) a Hub 1.0 impl, and as such 
> one implementation could not be mixed-and-matched with another. 
> This would allow for greater flexibility in sharing code between the
> two implementations. 
> 
> So, for example, there would be one JS file with 
> OpenAjax.hub.specVersion == "1.0" that implements the Hub 1.0 spec. 
> And there would be another JS file with OpenAjax.hub.specVersion == 
> "1.1" that implements both Hub 1.1 and 1.0 specs. 
> 
> Does this sound reasonable? 
> 
> 
> Javier H Pedemonte
> 
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Openajaxallianc-contributors mailing list
> Ope...@li...
> 
https://lists.sourceforge.net/lists/listinfo/openajaxallianc-contributors

[OpenAjax-Contributors] HUB: Hub 1.0 & 1.1 interdependencies

[Javier H P. <ped...@us...>]

A while back, someone brought up the point that the current reference 
implementation of Hub 1.1 depends on the Hub 1.0 code and makes use of 
internal methods (in particular, the methods that handle the subscription 
tree and wildcard support).  The issue is that because of this 
interdependency, the Hub 1.1 impl (OpenAjax-mashup.js) cannot be used with 
another Hub 1.0 impl.

One suggested solution was to standardize the Hub 1.0 internal methods and 
make them available such that any Hub 1.1 impl can work with any other Hub 
1.0 impl.

But this isn't ideal, since we would have to reopen discussion on the Hub 
1.0 spec, for what are mainly implementation details.

I think a better solution would be to stipulate that any Hub 1.1 impl also 
include (or be matched with) a Hub 1.0 impl, and as such one 
implementation could not be mixed-and-matched with another.  This would 
allow for greater flexibility in sharing code between the two 
implementations.

So, for example, there would be one JS file with OpenAjax.hub.specVersion 
== "1.0" that implements the Hub 1.0 spec.  And there would be another JS 
file with OpenAjax.hub.specVersion == "1.1" that implements both Hub 1.1 
and 1.0 specs.

Does this sound reasonable?


Javier H Pedemonte

Re: [OpenAjax-Contributors] HUB: handling asynchronous tests in JsUnit

[Javier H P. <ped...@us...>]

I've spent the past couple of days playing with the Dojo DOH testing 
framework, and I like it.  Seems a bit more structured than JsUnit, in 
addition to having proper support for asynchronous tests.  The 
documentation (
http://dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/d-o-h-unit-testing
) is on par with JsUnit (somewhat sparse), and it can be tricky to use if 
the tests don't use the Dojo packaging system.

But I finally got it working and redid the couple of JsUnit tests to now 
use DOH.  The relevant checkin is 
http://openajaxallianc.svn.sourceforge.net/viewvc/openajaxallianc?view=rev&revision=245
.  I've posted some rudimentary instructions in the 'UsingDojoDOH.txt' 
file.  Please have a look and run it, to make sure I haven't missed 
anything.

DOH has a command line interface, but that only runs tests using Rhino. It 
doesn't have support (as far as I can tell) for creating Ant based tests 
that automatically open in the specified browsers.  But it does have a 
nice automatic test runner -- just point the browsers to the appropriate 
URL and the tests run.

The tests I checked in make use of Dojo functions, but DOH itself doesn't 
depend on Dojo, and it should be pretty easy to remove that dependency 
from the unit tests, if necessary.

Please take a look and let me know what you think...


Javier H Pedemonte

Re: [OpenAjax-Contributors] HUB: handling asynchronous tests in JsUnit

[Javier H P. <ped...@us...>]

Sumeer Bhola wrote on 04/09/2008 10:26:46 AM:

> Looking at the tests you mentioned in /hub11/trunk/testsrc/
> TestPubSub, these seem to be synchronous since you are setting 
> setUpPageStatus="complete" at the end of the setUpPage() function. 
> For an asynchronous test, the technique you outlined below would 
> result in setUpPageStatus being changed to "complete" by the last 
> callback function in the series of asynchronous callbacks. Right? 

Good catch.  I've made the change in SVN.

The 1.1.2 test case isn't necessarily async since all the callbacks are 
called synchronously.  But I wanted to get the structure correct now, so 
that everything would work as is when testing with a provider that does 
async callbacks (such as SMash).


Javier H Pedemonte

Re: [OpenAjax-Contributors] HUB: handling asynchronous tests in JsUnit

[Sumeer B. <sb...@us...>]

Looking at the tests you mentioned in /hub11/trunk/testsrc/TestPubSub, 
these seem to be synchronous since you are setting 
setUpPageStatus="complete" at the end of the setUpPage() function. For an 
asynchronous test, the technique you outlined below would result in 
setUpPageStatus being changed to "complete" by the last callback function 
in the series of asynchronous callbacks. Right?

I agree it would be more convenient to move to a testing framework that 
explicitly supports asynchrony, but I have no experience with Dojo D.O.H. 
etc. 

Sumeer



ope...@li... wrote on 
04/07/2008 11:47:43 PM:

> 
> The Hub 1.1 APIs are primarily asynchronous, using callbacks for 
> results.  However, JsUnit doesn't really handle asynchronous tests. 
> The best way to do it is taking advantage of the setUpPage() method,
> which allows setup for all the tests on the page in an asynchronous 
fashion. 
> 
> I've checked in a couple of tests that take advantage of this. 
> Basically, I put the majority of each test case in the setUpPage() 
> method, allowing me to test using callbacks.  The actual test method
> on the page does the actual assert.  You can see the tests in 
> /hub11/trunk/testsrc/TestPubSub. 
> 
> There are a couple of disadvantages to this approach, though.  Since
> setUpPage() is only called once per page, that means that each test 
> has to have its own HTML page -- rather than having several 
> independent tests all in one page as done in the Hub 1.0 unit tests.
> Also, as a minor inconvenience, JsUnit doesn't allow asserts in the 
> setUpPage() method, only in the actual test function of the page. 
> 
> I've seen some other approaches for JS unit tests that handle 
> asynchronous operation, such as Dojo's D.O.H., but I haven't tested 
those. 
> 
> What does everyone think?  Do we stay with JsUnit and use the 
> approach outlined above?  Or move on to another testing framework? 
> 
> 
> Javier H Pedemonte
> 
-------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Openajaxallianc-contributors mailing list
> Ope...@li...
> 
https://lists.sourceforge.net/lists/listinfo/openajaxallianc-contributors

[OpenAjax-Contributors] HUB: handling asynchronous tests in JsUnit

[Javier H P. <ped...@us...>]

The Hub 1.1 APIs are primarily asynchronous, using callbacks for results. 
However, JsUnit doesn't really handle asynchronous tests.  The best way to 
do it is taking advantage of the setUpPage() method, which allows setup 
for all the tests on the page in an asynchronous fashion.

I've checked in a couple of tests that take advantage of this.  Basically, 
I put the majority of each test case in the setUpPage() method, allowing 
me to test using callbacks.  The actual test method on the page does the 
actual assert.  You can see the tests in /hub11/trunk/testsrc/TestPubSub.

There are a couple of disadvantages to this approach, though.  Since 
setUpPage() is only called once per page, that means that each test has to 
have its own HTML page -- rather than having several independent tests all 
in one page as done in the Hub 1.0 unit tests.  Also, as a minor 
inconvenience, JsUnit doesn't allow asserts in the setUpPage() method, 
only in the actual test function of the page.

I've seen some other approaches for JS unit tests that handle asynchronous 
operation, such as Dojo's D.O.H., but I haven't tested those.

What does everyone think?  Do we stay with JsUnit and use the approach 
outlined above?  Or move on to another testing framework?


Javier H Pedemonte

[OpenAjax-Contributors] IMPORTANT ANNOUNCEMENT: SourceForge project's URL has been changed

[Jon F. <jf...@us...>]

IMPORTANT ANNOUNCEMENT:

SourceForge sent out a notice telling its users that they are requiring=

that all users upgrade to their new URL scheme for SVN by June 29;
otherwise, SVN will quit working for you. (See
http://sourceforge.net/docman/display_doc.php?docid=3D31070&group_id=3D=
1#notice)

I believe that I have now updated our SourceForge project as they requi=
re.
Previously, the URL for our SVN back-end was:

     https://svn.sourceforge.net/svnroot/openajaxallianc/hub

and now it is:

    https://openajaxallianc.svn.sourceforge.net/svnroot/openajaxallianc=
/hub

I believe that everyone who is contributing to the SourceForge project =
has
to update the URL for attaching to our SourceForge project.

After making this change, I was able to checkout a fresh copy of the op=
en
source project into a virgin directory by issuing an "svn checkout
https://openajaxallianc.svn.sourceforge.net/svnroot/openajaxallianc/hub=
"
from the command line.

ONE OUTSTANDING PROBLEM:

One problem I haven't solved yet is what I need to do to get TortoiseSV=
N
working with this new setup. When I try to do anything in TortoiseSVN
(e.g., checkout or show log), I get an error dialog that says "PROPFIND=
 of
'/svnroot/openajaxalliance/hub/trunk': could not connect to server
(https://openajaxalliance.svn.sourceforge.net)". If anyone has suggesti=
ons,
please pass them my way.

Jon=

Re: [OpenAjax-Contributors] [OpenAjaxCommunicationsHub] maven and externals projects

[Greg W. <gr...@we...>]

Jon,

I will add a NOTICE file as is required with the apache license anyway.

cheers


Jon Ferraiolo wrote:
> Hi Greg,
> We need to make sure that the README and index.html files in the source
> control system are clear about all of this referencing and are clear
> that the referenced chunks of code (such as Dojo) have different IP
> policies. If you are so inclined, feel free to take a shot at updating
> the various files, or leave it to me. I will look at things afterwards
> anyways to add/modify descriptions if I see things that I think need
> further clarification.
> 
> Jon
> 
> Jon Ferraiolo <jf...@us...>
> Web Architect, Emerging Technologies
> IBM, Menlo Park, CA
> Mobile: +1-650-926-5865
> 
> Inactive hide details for Greg Wilkins <gr...@we...>Greg Wilkins
> <gr...@we...>
> 
> 
>                         *Greg Wilkins <gr...@we...>*
> 
>                         02/01/2007 12:40 AM
> 
> 	
> 
> To
> 	
> Jon Ferraiolo/Menlo Park/IBM@IBMUS
> 
> cc
> 	
> com...@op...,
> ope...@li...
> 
> Subject
> 	
> Re: [OpenAjaxCommunicationsHub] [OpenAjax-Contributors] maven and
> externals projects
> 
> 	
> 
> 
> Jon Ferraiolo wrote:
>> Hi Greg,
>> I went through the Maven documents. I assume that the dojo svn:externals
>> would go within the list of dependencies. If so, then my opinion is that
>> it is a good way to proceed. (In fact, maybe Maven should be used at the
>> core level of the Hub so that developers can pull down JSUnit.)
>>
>> So, I suggest that you go ahead and check in this change. If anyone
>> disagrees, speak up, and we can always remove it later if someone points
>> out a problem.
> 
> 
> Actually there are two things....
> 
> one is the use of maven, which as you say lets things like junit be
> downloaded
> during the build, can assemble war files for testing and can run ant targets
> for anything that does not fit with the rest of it.
> 
> 
> The svn:externals is a way to nail a bit of one repository into another
> repository.    So instead of checking in a copy of a dojo release into
> the test webapp, I can say to svn - please check out this version of dojo
> at this point in the svn tree.
> 
>   svn propset svn:externals 'dojo http://svn.dojotoolkit.org/dojo/trunk' \
>      hub/sandbox/communications/src/main/webapp
> 
> and then when one does svn update of the oaa hub tree, the version of
> dojo is checked out into the spot needed for the demo/test.
> 
> So there is no dojo in the repository, just a link to it.
> 
> Anyway, I shall wait another 24hr and if still no objections I will check it
> in.
> 
> cheers
> 

Re: [OpenAjax-Contributors] [OpenAjaxCommunicationsHub] maven and externals projects

[Greg W. <gr...@we...>]

Jon Ferraiolo wrote:
> Hi Greg,
> I went through the Maven documents. I assume that the dojo svn:externals
> would go within the list of dependencies. If so, then my opinion is that
> it is a good way to proceed. (In fact, maybe Maven should be used at the
> core level of the Hub so that developers can pull down JSUnit.)
> 
> So, I suggest that you go ahead and check in this change. If anyone
> disagrees, speak up, and we can always remove it later if someone points
> out a problem.


Actually there are two things....

one is the use of maven, which as you say lets things like junit be downloaded
during the build, can assemble war files for testing and can run ant targets
for anything that does not fit with the rest of it.


The svn:externals is a way to nail a bit of one repository into another
repository.    So instead of checking in a copy of a dojo release into
the test webapp, I can say to svn - please check out this version of dojo
at this point in the svn tree.

   svn propset svn:externals 'dojo http://svn.dojotoolkit.org/dojo/trunk' \
      hub/sandbox/communications/src/main/webapp

and then when one does svn update of the oaa hub tree, the version of
dojo is checked out into the spot needed for the demo/test.

So there is no dojo in the repository, just a link to it.

Anyway, I shall wait another 24hr and if still no objections I will check it
in.

cheers

Re: [OpenAjax-Contributors] maven and externals projects

[Greg W. <gr...@we...>]

Jon,

I had already checked in the maven stuff, but am holding off on checking in
the dojo svn:externals.

The stuff that is checked in appears to be working at least for FF.

There is a chatroom demo that is programmed against the proposed comms API.
There are two configurations/providers of the API, one for straight XHR and
the other for cometd.

I think it is a reasonable demonstration how the details of transport can
be well separated from the use of a comms API.... but obviously more examples
will be needed to really test the approach.

The XHR implementation works against a servlet that takes form encoded
data and produces XML.

The cometd version uses json in both directions.

The configuration of the connection factories includes encodePayload and
decodePayload methods that can work around these sort of differences.

One concern I have is how many utility methods we provide to map between
formats.  I have provided some conversion methods... but they are mickey mouse.
It could be a lot of code to provide an exhaustive set of converters.
Thus I think it best if converter utilities are provided by individual
implementations - as they may already have much of the code needed

Anyway, I have to move house back to Australia over the next week, so
I wont have much time to work on this or respond....  but I'll try to
stay in touch.

cheers



Jon Ferraiolo wrote:
> Hi Greg,
> I'm new to so many things in this world of Ajax, and now I see there is
> this thing called Maven. I will plow through the intro materials today
> to see if I see anything wrong with your approach. My inclination now is
> to advocate flexibility, *particularly* for things in a sandbox area,
> but I'll respond to the list with an opinion within a day (hopefully).
> 
> Jon
> 
> Jon Ferraiolo <jf...@us...>
> Web Architect, Emerging Technologies
> IBM, Menlo Park, CA
> Mobile: +1-650-926-5865
> 
> Inactive hide details for Greg Wilkins <gr...@we...>Greg Wilkins
> <gr...@we...>
> 
> 
>                         *Greg Wilkins <gr...@we...>*
>                         Sent by:
>                         ope...@li...
> 
> 
>                         01/31/2007 04:28 AM
> 
> 	
> 
> To
> 	
> ope...@li...
> 
> cc
> 	
> 
> Subject
> 	
> [OpenAjax-Contributors] maven and externals projects
> 
> 	
> 
> 
> 
> Hi all,
> 
> I'm currently working in the sandbox for the proposed hub communications
> 
> https://svn.sourceforge.net/svnroot/openajaxallianc/hub/trunk/sandbox/communications
> 
> I have used maven2 as the build tool as it allows me to pull in dependencies
> without checking them into svn.    once things are working, I will break the
> module up into source and test/demo code and then work on an ant build
> for it.
> 
> But for the demo, I would also like to use dojo, so I can show the
> comms working with direct XHR or with cometd.
> 
> Is it OK to checkin an svn:externals pointing to the dojo repository.
> This will not put dojo into the openajax svn, but will check it out when
> the oaa svn is checked out.     I can see that some would think this is
> sub-optimal from a clarity and marketing point of view.  So I am open to
> suggestions for alternatives.
> 
> But for now, is it OK to check that in as for expediency?
> 
> cheers
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
> _______________________________________________
> Openajaxallianc-contributors mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openajaxallianc-contributors
> 

[OpenAjax-Contributors] maven and externals projects

[Greg W. <gr...@we...>]

Hi all,

I'm currently working in the sandbox for the proposed hub communications

https://svn.sourceforge.net/svnroot/openajaxallianc/hub/trunk/sandbox/communications

I have used maven2 as the build tool as it allows me to pull in dependencies
without checking them into svn.    once things are working, I will break the
module up into source and test/demo code and then work on an ant build for it.

But for the demo, I would also like to use dojo, so I can show the
comms working with direct XHR or with cometd.

Is it OK to checkin an svn:externals pointing to the dojo repository.
This will not put dojo into the openajax svn, but will check it out when
the oaa svn is checked out.     I can see that some would think this is
sub-optimal from a clarity and marketing point of view.  So I am open to
suggestions for alternatives.

But for now, is it OK to check that in as for expediency?

cheers

[OpenAjax-Contributors] Build logic added for OpenAjax.js

[Jon F. <jf...@us...>]

FYI -

The project now has build logic to create OpenAjax.js. (Simple
concatenation of the 6 *.js files.) This enabled the following changes:

* I changed the build script (trunk/build.xml) such that OpenAjax.js is
recreated before the automated tests are run. (There is now an Ant build
target "OpenAjax.js")
* I changed the automated tests to load OpenAjax.js rather than the
individual *.js files.

I put the generated OpenAjax.js file into directory release/. I figured it
was cleaner to have src/ contain only original source files and not contain
anything that is generated.

I also complicated the testsrc/ directory a bit. There are now 2 small HTML
files for each test module:

* testsrc/_TestMarkupScanner_release.html - This is the HTML test file
loaded by the Ant-driven automated tests. It loads release/OpenAjax.js.
* testsrc/_TestMarkupScanner_src.html - This is the HTML test file that
developers would normally load into TestRunner.html. It loads
src/MarkupScanner.js.

These two files are just shims above testsrc/_TestMarkupScanner.js, which
holds the actual testing logic. The above two files will almost never
change.

[OpenAjax-Contributors] Before nuking the jsunit/ directory in the SVN project

[Jon F. <jf...@us...>]

We need to yank JSUnit from our SVN tree due to conflicts over IPR rule=
s
between JSUnit (GPL, MPL, etc.) and OpenAjax (Apache2). But before nuki=
ng
the jsunit/ directory from the SVN tree, I wanted to do some cleanup an=
d
get some verification from James (at least) that it was OK to get rid o=
f
this directory.

Here is one bit of cleanup that I have done so far. I noticed that Jame=
s
had put file "jsunit-server-properties.xml", which holds system-specifi=
c
data values such as the installation location of IE and Firefox, into
directory testsrc/. I felt that this was philosophically wrong. Directo=
ries
src/ and testsrc/ should not hold any programmer-specific configuration=

files. So, I moved this file into the /jsunit directory. (Right next to=

"jsunit.properties.sample" and "build.xml", each of which have the same=
 set
of configuration settings inside of them.) I think it is OK to put the
configuration options in that file because, once we nuke jsunit/ from t=
he
SVN repository, each programming will have to manually install JSUnit i=
n
the jsunit/ directory themselves. (I updated "trunk/build.xml" to point=
 to
the new location, so all of the automated testing things should still
work.)

I am pretty sure that James is the only other implementer who has been
working with JSUnit. Therefore, before I nuke the jsunit/ directory:

1) James, could you please send me an email saying that you have update=
d to
the latest SVN tree and that ANT-driven JSUnit testing works on your
system. (You'll notice that the ANT-driven tests now cover the entire H=
ub
implementation.)

2) I hope to clean up the various README files in the SVN tree to make =
sure
that new contributors also can figure out how to download and set up JS=
Unit
testing.

Jon=

Re: [OpenAjax-Contributors] Alex's comments and questions

[Alex R. <al...@do...>]

On Thursday 07 December 2006 1:46 pm, James Margaris wrote:
> (EMail bounced on first attempt)
>
>  This is a coding style issue. If you are going to remove constants
> and replace them with string comparison doesn't the developer have to
> memorize the strings?

as opposed to memorizing the location of the constant? And at the cost=20
of more verbose code?

> So now instead of registerCB(OpenAjax.KEntireString) I do
> registerCB("entire-string") or something like that? It requires the
> same amount of knowledge.

Right, which means that way that requires the least amount of code=20
should be preferred.

> That said, I don't like constants on classes. Without decent
> autocomplete, refactor menus and other such features they don't add
> much, at the expense of longer code. There really isn't a good way to
> handle this in JS, it's either have to look for the constant or look
> up some string...
>
> At some point we will need some coding conventions. For example
> constants starting with 'K' is a C convention, the Java equivalent is
> ENTIRE_STRING. Those sorts of decisions don't matter much until you
> start mixing files, internal consistency is what is important there
> IMO.

Might I suggest?:

	http://dojotoolkit.org/js_style_guide.html

Regards

=2D-=20
Alex Russell
al...@si...     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
al...@do... BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Re: [OpenAjax-Contributors] Alex's comments and questions

[James M. <jma...@ne...>]

(EMail bounced on first attempt)
=20
 This is a coding style issue. If you are going to remove constants and
replace them with string comparison doesn't the developer have to
memorize the strings?
=20
So now instead of registerCB(OpenAjax.KEntireString) I do
registerCB("entire-string") or something like that? It requires the same
amount of knowledge.
=20
That said, I don't like constants on classes. Without decent
autocomplete, refactor menus and other such features they don't add
much, at the expense of longer code. There really isn't a good way to
handle this in JS, it's either have to look for the constant or look up
some string...
=20
At some point we will need some coding conventions. For example
constants starting with 'K' is a C convention, the Java equivalent is
ENTIRE_STRING. Those sorts of decisions don't matter much until you
start mixing files, internal consistency is what is important there IMO.
=20
James Margaris
=20
---

(3) MarkupScanner.js
Alex says:
// FIXME: this "global constant" block is stupid, bordering on the
useless. Why
// are we not just doing string comparison instead of hoisting all this
cruft
// around and making users memorize either constants or look them up?

// Global constants
OpenAjax.KEntireString =3D 0; // For OpenAjaxType attribute analysis, =
must
match entire attribute value
OpenAjax.KInitialChars =3D 1; // For OpenAjaxType attribute analysis, =
must
match initial chars in attr value

Answer: I agree. I will remove this useful bordering on stupid approach
and replace with string comparisons.
Jon Ferraiolo <jf...@us...>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865

[OpenAjax-Contributors] Alex's comments and questions

[Jon F. <jf...@us...>]

YAY! Alex has looked at the latest source code. I have captured his
comments and questions.

(1) Serialize.js:
Alex asks:  // FIXME: why do we have this file? It's not referenced fro=
m
anything else. Is it actually part of the hub?

Response: This file is used by some of the test cases in ../testsrc.
Because of this, it probably belongs in ../testsrc, not ../src. But bef=
ore
moving the file, I plan to change all of the old tests from the previou=
sly
manual (non-JSUnit) test cases into automatic JSUnit test cases. (Proba=
bly
in the next couple of days.) Maybe there will be no need to serialize a=
fter
this switch to JSUnit, so maybe this file will disappear.

(2) GlobalsCollisionCheck.js:
Alex asks:
// FIXME: doesn't just checking for the existance of
// OpenAjax.globalsCollisionCheck do the same thing? Why is there this
strange
// registry hanging off the side?
/* Register that the GlobalsCollisionChec module has been loaded. */
OpenAjax.features["GlobalsCollisionCheck"] =3D true;

Answer: What I had in mind was trying to address download issues where =
an
application developer or toolkit developer might only use pieces of the=
 Hub
rather than the whole thing. The point of OpenAjax.features would be to=

provide a well-documented and standard mechanism that works across the
entire Hub for seeing which modules have been initialized. But this is =
at
best a half-baked mechanism. Unless someone objects, I will yank out
"OpenAjax.features".

 (3) MarkupScanner.js
Alex says:
// FIXME: this "global constant" block is stupid, bordering on the usel=
ess.
Why
// are we not just doing string comparison instead of hoisting all this=

cruft
// around and making users memorize either constants or look them up?

// Global constants
OpenAjax.KEntireString =3D 0;   // For OpenAjaxType attribute analysis,=
 must
match entire attribute value
OpenAjax.KInitialChars =3D 1;   // For OpenAjaxType attribute analysis,=
 must
match initial chars in attr value

Answer: I agree. I will remove this useful bordering on stupid approach=
 and
replace with string comparisons.

(4) OpenAjaxFirst.js
Alex says:
            // FIXME: why is it ever acceptable for us to be showing er=
rors
to
            // users? Alert is perhaps the worst possible thing we coul=
d be
doing
            // here.
            alert("OpenAjax initialization error: " + message);

Answer: I agree. I wrote this code several days ago when I was so much =
more
ignorant and already had a note to myself to make sure all such similar=

bits of code are removed. (I believe there are several other places tha=
t
might produce alerts.) I will fix this. I'm not sure at this time exact=
ly
how to address it, but I suspect this routine can just be removed (best=
 fix
of all).

Thanks, Alex!

Jon

Jon Ferraiolo <jf...@us...>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865=

[OpenAjax-Contributors] Global change from oaa to openajax

[Jon F. <jf...@us...>]

Hello fellow contributors to the OpenAjax SourceForge project,

Yesterday, I did a global search/replace of "oaa" to "openajax" in the open
source project. Thus, our global object is not the "openajax" object.

Jon

(I am sending this partly to communicate this change, but also to see how
things are working with this mailing list.)

[OpenAjax-Contributors] Welcome to the first 8 contributors

[Jon F. <jf...@us...>]

Hi everyone,
As discussed at today's phone call, I created
ope...@li.... I subscribed the
following eight people (our initial set of Contributors to the open source
project):

al...@do...
jf...@us...
jma...@ne...
joo...@it...
ls...@fi...
ric...@su...
vs...@us...
vva...@se...

(My other assignment was to create a Tracker for Bugs, but that already
existed. Instead, I disabled the other standard trackers that SourceForge
makes available by default.)

Jon

Jon Ferraiolo <jf...@us...>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-464-7817

[OpenAjax-Contributors] test

[Jon F. <jf...@us...>]

test