Architectural Changes (for 3.0)

[GoogleCodeExporter]

The proposal is to modify the inheritance of classes in JxLib to introduce some 
new objects.  The purpose of the change is to make 
implementation of some other changes easier.  This is a very rough first pass 
at the changes I am thinking of making ... comments 
required!

== Jx.Object ==

Implements: Options, Events

This is a new class that would be the base class for all Jx classes.  This 
class would Implement Options and Events so that all Jx classes 
would inherit these.  In addition, this new class could provide the API for 
saving and restoring state of Jx objects.  Specific sub-classes 
would then be able to participate in saving and restoring their state.

== Jx.View ==

Extends: Jx.Object, ToElement, Occludes, Jx.Chrome
HasA: element -  the DOM element of this Jx object

This is a new class that would be the base class for all Jx classes that have a 
visual representation in the page.  This would Implement 
Jx.Addable (or clientcide ToElement) and possibly Jx.Chrome so any visual 
object could have drop shadows or other non-interactive 
adornments.

Note: I'm not particularly happy with the name for this class but I don't have 
a better name yet, suggestions welcome.

== Jx.Container == 

Extends Jx.View
HasA: Jx.Layout

A Jx.Container is a visible element that you can add other Jx things to and 
manage their display using a layout

== Jx.Layout ==

Extends: Jx.Object

This would remain but would become a base class for other types of layouts and 
the current implementation would become 
Jx.Layout.Anchored (or something like that).

== Jx.Viewport ==

Extends: Jx.Container

exactly fills the page (replaces doing a Jx.Layout('thePage')) and allows you 
to add things to it to be managed by the selected layout.

Most of the existing classes would end up extending Jx.View and a couple would 
extend Jx.Object directly.  There would be no immediate 
functional change but it would allow us to streamline some code and introducing 
a rendering pipeline with more events that would allow 
developers a bit more control.  We would also be able to add other layout 
options and eventually introduce some kind of state 
save/restore capability.

Original issue reported on code.google.com by pagameba on 16 Apr 2009 at 9:33

[GoogleCodeExporter]

Not many initial comments as I'll need to mull this over a bit. My gut says 
this is
definitely the way to go.

A suggestion on Jx.View name - Jx.Component?

Original comment by jbomgard@gmail.com on 16 Apr 2009 at 10:08

[GoogleCodeExporter]

I was trying to not copy ExtJS too much :)

Original comment by pagameba on 17 Apr 2009 at 12:09

[GoogleCodeExporter]

I just went and looked... I didn't even realize I did that :) I've looked into 
ExtJs
before and it must have stuck... I'm sure we can come up with something 
though...
Jx.View isn't bad

Original comment by jbomgard@gmail.com on 17 Apr 2009 at 5:56

[GoogleCodeExporter]

How about Jx.Widget?

Original comment by jbomgard@gmail.com on 17 Apr 2009 at 3:18

[GoogleCodeExporter]

We have a winner!  I'm a big fan of widgets!

Original comment by pagameba on 17 Apr 2009 at 5:05

[GoogleCodeExporter]

So over my lunch I decided to throw together some crude UML diagrams as to how 
this
may lay out over the entire existing codebase. Take a look and let's discuss if 
this
is the way it would work or if some things should be different.

There are three different files as the tree was rather large and messy. The 
names of
each indicate the starting point (Jx.Object, Jx.Widget - if that's the name 
we'll
use, and Jx.Container)

Original comment by jbomgard@gmail.com on 22 Apr 2009 at 8:41

Attachments:

• Widget.cld.jpg

[GoogleCodeExporter]

quick review in passing, thanks for attempting this (I tried something similar 
but couldn't find a good uml tool 
for my mac so I gave up).

I was thinking that Jx.Chrome and Jx.Addable would be merged into Jx.Widget.  
If  not then they probably 
would not inherit from Jx.Object but rather be like Options and Events.   Same 
for Jx.ContentLoader, 
Jx.AutoPosition I guess.

I think TabBox might be a container rather than a widget, not sure about that 
one.

Original comment by pagameba on 22 Apr 2009 at 9:39

[GoogleCodeExporter]

I was actually thinking the same as far as the mixins. I was just trying to map 
out
the existing code. I'll make those changes. TabBox I think should definitely be 
a
container, same for toolbar.container.

Original comment by jbomgard@gmail.com on 23 Apr 2009 at 3:14

[GoogleCodeExporter]

I've made those few changes and also fleshed out Jx.Widget a bit to show it 
contains
what was Chrome, ContentLoader, AutoPosition, and Addable.

I did these in AmaterasUML which is an Eclipse plugin (I use Eclipse 
extensively). If
you decide to use this I can put the actual editable diagrams into the 
repository.

Original comment by jbomgard@gmail.com on 23 Apr 2009 at 8:33

Attachments:

• Container.cld.jpg
• Object.cld.jpg
• Widget.cld.jpg

[GoogleCodeExporter]

I'm attempting to set up eclipse and the plugin you indicated.  Can you put the 
diagrams into svn somewhere?

Original comment by pagameba on 24 Apr 2009 at 11:57

[GoogleCodeExporter]

I've placed the docs in a docs folder in the root of the svn.

Original comment by jbomgard@gmail.com on 24 Apr 2009 at 5:30

[GoogleCodeExporter]

so I've got eclipse and installed amaterasuml and its dependencies (uml2 and 
gef) and it seems to be working in 
as much as I can create new amateras diagrams but ... when I try to open one of 
the class diagrams from svn it 
fails with "Could not open the editor: org.eclipse.ui.ide.FileStoreEditorInput" 
and if I create a new class diagram, I 
can't actually create classes in it, just interfaces and notes.  The other 
diagrams seem to work.  Note that I am a 
total eclipse newbie so any pointers would be extremely helpful.

Original comment by pagameba on 1 May 2009 at 2:56

[GoogleCodeExporter]

I'm setting the plugin up on a new machine this weekend so I'll let you know if 
I
find anything that might help.

Original comment by jbomgard@gmail.com on 2 May 2009 at 12:00

[GoogleCodeExporter]

So, I tried to set it up and had the same problem on a Linux machine. It turns 
out
that the solution is to be sure you're using Java version 6. Once I switched my
default JVM to that it worked fine. It seems to be relying on a method of the 
Java
Array class that is not present in earlier versions. 

Also, it should work with both the official sun version or openjdk. I've tested 
both.

Original comment by jbomgard@gmail.com on 2 May 2009 at 4:07

[GoogleCodeExporter]

darn - javase 6 for OS X is only 64bit and eclipse 3.4 is using carbon so it 
will only pick a 32bit java - I'll have to 
do this in a windows vm until eclipse 3.5 works with javase 6 (current builds 
only work with 5)

Thanks for the pointers, I'm sure once that is sorted I'll be able to run it 
... until then, I do have some windows 
VMs I can use.

Original comment by pagameba on 2 May 2009 at 6:24

[GoogleCodeExporter]

so how do we proceed here?

Original comment by jbomgard@gmail.com on 14 May 2009 at 10:57

[GoogleCodeExporter]

I've given up on trying to get amaterasuml working, but I have reviewed the 
diagrams for this and the data 
store and grid proposals.  Now that 2.0 is out the door, I think we can proceed 
with the proposed changes.

I'd like to start with refactoring the existing code into Jx.Object and 
Jx.Widget and combining some of the 
mixin classes into the right places.  I am still not sure about Jx.Container 
and the changes needed for that.

Jon, you seem pretty keen on the grid stuff and I think that will take a fair 
amount of effort to get functional 
so I'd like to let you run with that once Jx.Object and Jx.Widget are roughed 
in, then I can take care of 
Jx.Container and the layout things I was thinking of.  For Jx.Object and 
Jx.Widget, I don't have a lot of time to 
put into this in the next couple of weeks as I have some work deadlines looming 
so if you want to take a crack 
at them, at least as much as you require for the data store and grid changes, I 
can come along behind you 
and work the existing code into that structure after the fact.

How does this sound?

Original comment by pagameba on 15 May 2009 at 1:05

[GoogleCodeExporter]

Sounds good to me. I'll start getting things in order.

Original comment by jbomgard@gmail.com on 15 May 2009 at 5:43

[GoogleCodeExporter]

Made initial changes to common.js to create Jx.Object and Jx.Widget. In the 
common.js
file I've made a few notes about things to look at. 

1) I'd like to take the image loading code and move it into a class of it's own 
-
perhaps Jx.Preloader. It could be fleshed out to be a bit more full featured.

2) I've looked through the element extensions and noted which ones could be 
replaced
by mootools-core or -more equivalents (or nearly equivalents). Take a look at 
the
notes and see what you think about removing, or rewriting to take advantage of
existing mootools functions. We'll then have to note the additional dependency
somewhere (either depednecy for common or possibly for Jx.Widget).

Original comment by jbomgard@gmail.com on 17 May 2009 at 6:47

[GoogleCodeExporter]

Looks good!

For the image loading code, that is a bit of legacy, I am not sure what to do 
with it.  The problem it was trying 
to solve was caused by many Jx.TreeItems requesting images that took some time 
to generate in our web 
mapping framework.  Because of the limits of simultaneous connections in 
browsers, several hundred of these 
requests would essentially stop any other functionality from happening 
including loading the main map 
image.  The queue minimized this problem by limiting the number of tree item 
images to only two 
simultaneous downloads at a time, allowing other http requests to also be 
fulfilled.

I am not sure this really belongs in Jx, it seems like we should move it out 
entirely and put it into the web 
mapping framework.  What we would need instead is a way to delegate populating 
image sources to a 
function supplied by the user of JxLib but I am not quite sure how to go about 
that yet.  If we can come up 
with a way to make that change then it solves the problem in a more generic way 
and isn't JxLib's problem any 
more.

Looking through the list of potential replacements, I think you are mostly or 
completely right.  We'll need to 
get the code running in order to make sure the element sizing stuff works the 
same way.  We rely heavily on 
get/set margin/content size to make things fit together properly across all 
browsers.  As long as 
getComputedSize returns the same values, its a natural replacement and would 
eliminate a bunch of code!

On getting the code running ... with the removal of the mixin classes, all 
other classes will have to be 
modified to extend Jx.Widget or Jx.Object before they will work correctly I 
think.

I am having some second thoughts about Jx.Widget containing all the mixin code, 
for instance many widgets 
don't require the content loading stuff and it could be abused by folks calling 
loadContent on buttons for 
instance.  I don't think it matters for performance, its more of an 
architectural decision I guess.  Any 
comments for or against?  The more I think about it, the more I think I 
shouldn't worry about it.

One request, can you change your text editor to use spaces instead of tabs?  
Specifically 4 spaces per tab :)  

Original comment by pagameba on 17 May 2009 at 10:01

[GoogleCodeExporter]

Personally, I'd like to leave the image loading code in but make it a class that
could be used (I know I'd use it). On the other hand, a generic delegate 
solution
would allow any such solution to be used and thus would probably be preferable.

As to the mixin code, specifically contentLoader... do you think it would be a 
more
natural fit to live inside Jx.Container rather than Jx.Widget?  That would 
prevent
it's being used in unintended places but still make it available to those 
classes
that need it.

As for the tabs... I'll either figure out how to do it or I'll just space 
everything.

Original comment by jbomgard@gmail.com on 18 May 2009 at 3:47

[GoogleCodeExporter]

in r443, modified existing code to extend Jx.Object or Jx.Widget directly and 
removed Implements from 
everywhere.  Code quickly tested, everything seems to run.  Only problem was 
Jx.Tree which uses this.addable 
for Jx.Addable, addTo did not pick up this.addable as an alternative to 
this.domObj so I added it and now all 
good.

Original comment by pagameba on 21 May 2009 at 1:34

[GoogleCodeExporter]

This is a carry-over from my post in the google group... I'm adding it here so 
that
it is tracked (seems like the best place for it). I also made some changes to 
it:

1) Pretty much no Jx class should have an initialize() method. All classes would
instead have an init() method that will be called by Jx.Object. If a class 
descends
from Jx.Widget it should also provide a render() function. init() should be 
used for
setting up member variables and the like and render() should be used for 
actually
creating the widget.

2) Jx.Object would then look something like this:

initialize: function(options) {
   this.setOptions(options);  
   this.fireEvent('preInit');
   this.init();
   this.fireEvent('postInit');
   this.fireEvent('prePluginInit');
   this.initPlugins();
   this.fireEvent('postPluginInit');
   this.fireEvent('initializeDone');

}

3) Jx.Widget.init() would look something like this:

init: function() {
   this.fireEvent('preRender');
   this.render();
   this.fireEvent('postRender');
}

Obviously, that just sets up a pipeline for rendering and fires off
events that can be listened for. Also, all classes that extend from Jx.Widget 
would
need to be sure to call this.parent() inside their init() functions. I'm also
thinking about adding an option called 'deferRender' that would enable you to 
bypass
the rendering phase of creation if you needed to have the object wait to create 
its
interface - though I don't know how useful that would be.

4) The plugin initialization code would then be in Jx.Object.initPlugins() which
would give all classes the ability to use plugins if they want. If they do, they
should also define a pluginNamespace member variable that will be used in the
initPlugin() code to namespace the plugins (should probably default to 
something but
I'm not sure what).

Thoughts?

Original comment by jbomgard@gmail.com on 9 Sep 2009 at 2:54

[GoogleCodeExporter]

Another thought (on a slightly different topic)...

I was thinking about adding a couple of other methods to Jx.Widget:

1) Jx.Widget.removeFrom() - would remove the widget from DOM but not destroy it.
simply a convenience wrapper for the mootools function that removes from the 
DOM but
doesn't destroy the element (that I can never remember).

2) Jx.Widget.destroy() - gives all objects the ability to be destroyed cleanly. 
It
would look for all of the standard member variables we use such as domObj, 
addable,
and domA and call their destroy methods as well as call a generic cleanup() 
method
that a class could implement to provide custom cleanup (close stores, save data 
to
server, etc...). My initial thought was that it would look like this:

destroy: function() {
    this.fireEvent('preDestroy');
    this.cleanup();
    if ($defined(this.domObj)) {
        this.domObj.destroy();
    }
    if ($defined(this.addable)) {
        this.addable.destroy();
    }
    if ($defined(this.domA)) {
        this.domA.destroy();
    }
    this.fireEvent('postDestroy');
}

Original comment by jbomgard@gmail.com on 9 Sep 2009 at 3:04

[GoogleCodeExporter]

Re comment 23, I've thought this through and while I am not entirely happy with 
not using initialize in all the 
classes, I think this is the most practical solution to the problem.  The more 
that I think about it, the more I 
am becoming a fan of adopting this approach.  Jon, are you going to make these 
changes to the existing code 
base or do you want me to?

Re comment 24 1), removeFrom() perhaps should be just remove() or dispose() 
(that's the name you are 
looking for I think) - I agree with adding this

Re comment 24 2) destroy is an excellent idea, we should add that at the 
Jx.Object level and implement 
everywhere

Original comment by pagameba on 17 Sep 2009 at 12:58

[GoogleCodeExporter]

I've actually started making these changes already (since I hadn't heard back 
from
anyone on it for a while I decided to test it out locally). I'm currently in the
process of testing out the changes and could have something committed in a 
couple of
days.

The only issue I ran into was that several classes required several initialize
parameters. I think I've worked out a way around this however. Once I commit the
changes I'd like some feedback regarding that particular work around.

Original comment by jbomgard@gmail.com on 17 Sep 2009 at 3:59

[GoogleCodeExporter]

changes made and committed in r524. I ran them through the spec tests, 
interactive
tests, and chaecked all of the examples. Hopefully everything is working 
properly.
Please give it a try and let me know if anything needs help.

Original comment by jbomgard@gmail.com on 18 Sep 2009 at 5:44

[GoogleCodeExporter]

seems to work well, thanks Jon!

Original comment by pagameba on 18 Sep 2009 at 12:38

[GoogleCodeExporter]

Original comment by fred.war...@gmail.com on 2 Nov 2009 at 3:52

• Added labels: Priority-High

[GoogleCodeExporter]

Original comment by pagameba on 2 Nov 2009 at 4:19

• Added labels: Milestone-3.0

[GoogleCodeExporter]

Original comment by fred.war...@gmail.com on 2 Nov 2009 at 4:50

• Changed state: Started

[GoogleCodeExporter]

I believe we have implemented the bulk of the changes suggested and discussed 
in this issue with the exception of Jx.Container and Jx.Layout.  
I am pretty happy with the changes as implemented, and I am not feeling the 
need to implement Jx.Container or the changes to Jx.Layout.

I am closing this issue now as I consider the architectural changes complete.  
If any of the developers disagree, please reopen the issue and 
discussion :)

The only downside to not making changes to Jx.Layout at this time is that it 
would be an intrusive change to introduce at a later time in that it 
would require major updates to existing applications which make use of 
Jx.Layout (but it would be a search-and-replace change, so maybe 
that's not too bad).

The Jx.Container change would, I think, be less invasive and could be 
introduced without an API change.  Perhaps we can come up with a way to 
introduce other layouts without requiring a namespace change on the existing 
Jx.Layout, which would avoid problems there too.

If we think Jx.Container and Jx.Layout changes, as proposed here, are good 
ideas then I suggest that we start a new issue to describe them and 
target the issue to a future milestone.  At this point, I am not going to start 
this new issue unless someone wants to champion it.

Original comment by pagameba on 2 Mar 2010 at 3:51

• Changed title: Architectural Changes (for 3.0)
• Changed state: Fixed

[GoogleCodeExporter]

I think Jx.Container and Jx.Layout changes as described are a great idea and 
will 
take on pushing them forward. I don't believe Container will create any major 
breaking changes (as a matter of fact we already have an example of a container 
in 
Jx.Panel) and I think I have an idea of how to make Jx.Layout not break to 
severely 
either... 

I will open a separate issue (at a later time) but target them at a later 
milestone.

Jon

Original comment by jbomgard@gmail.com on 3 Mar 2010 at 10:44

[GoogleCodeExporter]

I don't mind working on them either, I just don't want to interrupt our current 
flow towards a jxlib 3.0 release :)

Original comment by pagameba on 3 Mar 2010 at 10:57

[GoogleCodeExporter]

agreed... which is why I'll back-burner this and open a new issue at a later 
date :)

Original comment by jbomgard@gmail.com on 4 Mar 2010 at 12:22