XAP 0.3.0 tag

[James Margaris <jm...@nexaweb.com>]

The last tag we put down is pretty out of date, I'm going to replace the
stuff there with the latest from repository. The tag is supposed to
reflect the release but since it was made there have been a lot of
changes.

I also want to check a bunch of things in at some point soon. As the
release is nearing completion does anyone mind if I check stuff into the
trunk and we do the release off the tag? That would mean that we have to
make changes in both the tag and trunk, but hopefully those will be
minor license changes.

I am a big fan of continuous integration, I'm afraid that the longer I
wait the more my changes will diverge from what other people are working
on, and I have a *lot* of changes.

James Margaris

Vertical and horizontalBoxPane redux

[James Margaris <jm...@nexaweb.com>]

After much struggle I think these both should be working well.

The "boxFlex" attribute is now supported, allowing multiple components
within the layout to stretch in proportion to their box flexes.

It seems to work on IE6, IE7 and FF.

James Margaris

Changes to BorderPane

[James Margaris <jm...@nexaweb.com>]

Right now BorderPane uses a passive layout rather than an active one.

Passive layout: A layout based on tables or CSS that the browser can
handle without code.
Active layout: A layout that is performed by code that must be called
when the container changes size.

Passive layouts are a better strategy in general because they don't
suffer from weird visual quirks during resizing, don't require code, and
integrate better with plain HTML and other HTML widgets. For an active
layout you have to detect when the size of something changes and cascade
that down to children, which is tricky.

However, certain things are simply not achievable with a passive layout.

The BorderPane we have today works well in Mozilla but in IE it does not
work, it sizes too large vertically. (It does work in quirks mode in IE,
but quirks mode has plenty of other problems)

Our strategy was to divide a border pane into three rows, with the
middle row set to height 100% and the middle cell of the middle row set
to width 100%. In IE this will unfortunately ALWAYS make the center row
100% of the table size as set, which then forces the table to grow
vertically. So if you try to make a 300x300 table it might size to
300x360 instead. (If the the top and bottom rows are both 30px tall)

Converting BorderPane to an active layout fixes these problems. I'm
going to check in a new BorderPane that uses active layout, I've tested
all the samples and they seem to work ok. 

I would expect some difference in behavior if you don't set the size of
the BorderPane initially or put it in something like a splitPane that
fixes the size. Under the old scheme the size of the borderPane would
end up calculated as relatively correct because the components were
stuck in a table with the appropriate structure. Now all the children
are just random stacked divs until the borderPane performs layout.

This is annoying, but I would rather have a borderPane that works the
same on all browsers than one with some better edge-case behavior that
doesn't work for simple cases in IE.

James Margaris

Some class name changes

[James Margaris <jm...@nexaweb.com>]

Just a head's up, I am changing JsFormatterImpl to AbstractFormatter to be in line with our existing naming, so anyone extending that class needs to make that change. Of course I am changing all the checked-in code to reflect this.

I am also removing DataSetFactory but I doubt any external code would use this.

James Margaris

Re: XAP 0.3.0 tag

[robert burrell donkin <ro...@gmail.com>]

On 2/10/07, James Margaris <jm...@nexaweb.com> wrote:
>  So I created a 'XAP_0.3.0_RC2'
>
> If nobody objects I will delete the old one, as it serves no purpose.
> And start checking things into trunk again. I'll wait till at least
> Sunday afternoon/evening EST to do either.

subversion tags are cheap so there are no good reasons to delete them
but many good reasons to keep them. here are a couple:

the tag serves as a record of the process which create the release.
public development allows anyone who's interested to follow the
process now or at some time in the future. even given our best
efforts, real development is a messy and imperfect process. there is
no reason to hide this from the community.

there are pragmatic reasons for retention. occasionally, rogue
artifacts turn up possibly years down the line. it's a lot easier to
verify and understand them if the original tags are preserved.

- robert

Re: If you see a ton of changes next time you diff trunk blame me...

[robert burrell donkin <ro...@gmail.com>]

On 2/10/07, James Margaris <jm...@nexaweb.com> wrote:
> So I accidentally deleted trunk...(I blame eclipse, I swear I did not
> even touch my trunk checkout at all)

wow! would that be a bug or just an undocumented feature ;-)

what version of which plugin are you using for svn access?

> It should be back now to the state it was directly before I deleted it.
> On my machine after doing a diff I see a bunch of incoming files but
> when I compare the two files I see no actual changes...just a
> consequence of the delete and revert?

i've take a quick look and it's beyond me

a number of the subversion developers are in the apache infrastructure
team. might be worth seeing if anyone's hanging out on IRC who might
be able to shed some more light on what exactly happened...

- robert

Adding a new component to bug database

[James Margaris <jm...@nexaweb.com>]

I'm adding "layouts" as separate from widgets. Will move existing bugs
there as applicable.

James M

Where to next and using JIRA for task tracking.

[James Margaris <jm...@nexaweb.com>]

1. We should use JIRA for task tracking, not just bugs. Will make life easier for coordination, testing, etc.

2. We should start a discussion about next steps. Some thing I have in mind:

Performance of all kinds. (Startup and shutdown, memory, etc)

Drag drop support

Better table/tree/treeTable

General rounding out of widgets

Continuous code cleanup

Better documentation, both jsdoc and more general how to build, run, get started, etc

Potentially integrating some Yahoo UI widgets.

---

The last one requires a bit of explanation. YUI has come a long way in a short amount of time, as has YUI-EXT. (Extra widgets and functionality) YUI code is very nice and the documentation is also very nice. YUI widgets also look very nice and seem pretty stable and functional.

I am particularly interested in tree and table. (And some combination of those into a treetable??) A proper table has a lot of functionality - column sorting, resizing, swapping, one-click editors, etc. Maintaining our own table is pretty painful.

However there are some benefits in that our table is a combined tree/table/treeTable in one set of code. AFAIK neither Dojo nor YUI have a good tree table.

I would like to at least do some investigation into YUI. There are many factors to consider - will it integrate with Dojo loading code (and do we even want to do that), is it easier to work with?

The main thing I like about YUI is the level of polish it has. It doesn't cover nearly the breadth of the Dojo libs but what it does do it seems to do better.

 

James Margaris

Don't bother trying my box pane "fixes"

[James Margaris <jm...@nexaweb.com>]

The fixes I made hang IE6 and content comes out the wrong height on IE7...

 

I'll check in a better set of fixes in the next 24 hours, as soon as I can work through a dojo bug where setOuterHeight() doesn't work for tables...

 

James Margaris

Whole bunch of changes

[James Margaris <jm...@nexaweb.com>]

Ive checked in all the changes I've made recently, including the new
logging stuff and removal of a bunch of old/unused junk, along with some
refactoring.

Unit tests run but I'm sure I messed something up in the merge. Will
check again tonight on my home machine for incoming changes and try all
the samples/demos.

James Margaris

RE: XAP 0.3.0 tag

[James Margaris <jm...@nexaweb.com>]

 So I created a 'XAP_0.3.0_RC2'

If nobody objects I will delete the old one, as it serves no purpose.
And start checking things into trunk again. I'll wait till at least
Sunday afternoon/evening EST to do either.

James Margaris

-----Original Message-----
From: James Margaris [mailto:jmargaris@nexaweb.com] 
Sent: Friday, February 09, 2007 6:52 PM
To: xap-dev@incubator.apache.org
Subject: XAP 0.3.0 tag

The last tag we put down is pretty out of date, I'm going to replace the
stuff there with the latest from repository. The tag is supposed to
reflect the release but since it was made there have been a lot of
changes.

I also want to check a bunch of things in at some point soon. As the
release is nearing completion does anyone mind if I check stuff into the
trunk and we do the release off the tag? That would mean that we have to
make changes in both the tag and trunk, but hopefully those will be
minor license changes.

I am a big fan of continuous integration, I'm afraid that the longer I
wait the more my changes will diverge from what other people are working
on, and I have a *lot* of changes.

James Margaris

If you see a ton of changes next time you diff trunk blame me...

[James Margaris <jm...@nexaweb.com>]

So I accidentally deleted trunk...(I blame eclipse, I swear I did not
even touch my trunk checkout at all)

It should be back now to the state it was directly before I deleted it.
On my machine after doing a diff I see a bunch of incoming files but
when I compare the two files I see no actual changes...just a
consequence of the delete and revert?

James Margaris