Change log: 3.0 Glory

From version: Q1 2008 Tranquility (released 15th of February 2008)
To version: 3.0 Glory (released 3rd of July 2008) b

FEATURES

Added "handle" support for AspectDraggable.

Any child element of the control can be specified as
drag handler for the control. Both HTML and
server-side controls are supported. The recommended
way is to use server-side controls.

Added up "Silent" property in AspectDraggable which

will if true not check for Droppables. This will
especially for IE execute the draggable much faster
but will also make the "HoverClass" for the
Droppables not work.

Added up "effect" property for AspectDraggable which

will if anything else than 1.0 declare an opacity for
the dragged control between 0.0 and 1.0 where 0.0 is
invisible and 1.0 is 100% visible that will be applied
for the control when it is being dragged.

Added up "effectIfHit" property for AspectDraggable

which if true will override the revert property for
the AspectDraggable and REMOVE the reverting in
addition to that it will DropOut the Draggable widget
and Pulsate the Droppable widget.
This one is very useful for elements which are being
dragged and MOVED on the server from one container
widget to another.

Domains are now checked if hosted on www host. That

means a license entry for ajaxwidgets.com also applies
to www.ajaxwidgets.com. This was intended behaviour in
the first place, but we forgot to add this additional
check for some reason.

Changed the name of AspectDropable to AspectDroppable

since that was actually a typo.
BREAKING CHANGE!

Changed the constructor(s) to AspectResizable to

conform more to the constructors of the other Aspects.
BREAKING CHANGE!
You might get some compilation errors in your code if
you were using this Aspect from before, but it´s just
to rearrange the parameters to the call to the
constructor a little bit and you should easily fix them.

Added up properties for all data members of all

Aspects.

Added up serialization support for "non-Gaia" controls.

This means that you can now easily combine Gaia with
conventional ASP.NET controls without having to turn
of EventValidation and ValidateRequest.
In addition this should fix several bugs with DNN and
SharePoint etc. If you had obscure problems with
pages that contains a mix of Gaia Controls and
"non-Gaia" Controls then this is probably the reason.

In Release builds of Gaia the "common" JavaScript files

will now be concatenated to reduce HTTP requests which
will significantly improve responsiveness of applications.

Added up an XhtmlTextWriter class which uses the

IDisposable pattern to close tags. This is a far
superior way of creating XHTML compliance markup
in C#. We´re internally using this in Gaia
ourselves too which should increase the readability
of the library by a lot.

By implementing caching of PropertyInfo objects

in PropertyStateManagerControl class we´ve
effectively optimized Gaia by orders of magnitudes
and most Gaia applications should run at least
10-40 times faster on the server and also require
far less server resources. This means that your
application can effectively take far more requests
per time unit and still spend far less server
resources.

Added up support for having updaters on a

"per widget" basis. This means that any widget can
have its own UpdateControl by utilizing the
AspectUpdateControl which then will "override"
the global UpdateControl logic.

Added up support for setting the Callback URL

for pages. Some URL Rewriting modules creates
URL which are not reflected into the Callback URL
of Gaia. If you´re having problems with this then
the "CallbackURL" property of the Manager class
might be an option for you to use.

Implemented support for Double Click on

AspectClickable. Now you can trap Click events,
Double Click events or both.

Added support for saving DynamicImage as GIF

and PNG in addition to JPEG which was the only
option before.

Removed Gaia PlaceHolder, the reason is that it

more or less is an exact overlap of Gaia Panel.
To render a PlaceHolder the way ASP.NET would
render it is impossible with Gaia and the end
result for Gaia PlaceHolder is the exact same
as the Gaia Panel and therefor we have removed
it to avoid redundancy.
BREAKING CHANGE!!
Exchange all Gaia PlaceHolder with either
ASP.NET PlaceHolders or (preferably) Gaia
Panels.

Removed an XHTML compliance bug in DynamicImage

which rendered & instead of & as separators
between GET parameters of DynamicImage. This
is now fixed.

Removed "wrapper span" logic in library which

have made the whole library 100% XHTML
compliant. This has in addition had the
positive side effect of increasing the speed of
the JavaScript parts of Gaia by orders of
magnitudes. In addition the amount of HTML
generated on a Gaia Website is decreased by up
to 40%.

Completely re-created the TreeView Control!

The new TreeView control is 100 times more
flexible and easy to use than the previous
one. First of all you can now have ANY type
of widgets inside a TreeViewItem since the
TreeViewItems are first of all controls and
second of all CONTAINER controls. This means
that you can add up CheckBoxes, HyperLinks
"pure text" and anything you desire as
parts of your TreeViewItem controls.
Also the TreeView is now a 100 times easier
to skin since it now relies completely on ul
and li elements to render its HTML.
This also means that the current TreeView
control is search engine friendly for its
"static" elements. (the ones rendered in
the .ASPX or added up in the initial
Page_Load)
BREAKING CHANGE!!
This WILL break your current project´s
usage of TreeView since the new TreeView
has a different API. The new TreeView
can be found in the "Extensions" project.

Completely re-written the Menu widget.

The new Menu Widget (called Toolbar) is
first of all 100 times more flexible and
rich in UI. Second of all it solves a lot
of the problems the previous one had. Among
other things it is a LOT easier to skin
the current menu than the previous one.
Second of all the new menu is Search Engine
friendly since it renders HTML from the
server and does not initialize the DOM
from the client.
But most importantly the new Menu (still
called Toolbar) has support for adding
CHILD controls since it is now effectively
a Container Widget. This means you can
add up ANY Widget inside a Menu Item
(ToolbarItem) and have it rendered.
Including normal "ASP.NET" HyperLinks and
"static text" plus CheckBoxes and
everything you desire.
BREAKING CHANGE!!
This WILL render incompatibilities
towards your current usage of Menu since
the new menu has a new API.

Brand new Widget; ExtendedPanel

The ExtendedPanel is basically a thing mid
between the Gaia Window and the Gaia Panel.
If you want to have a "lighter Window" than
the Gaia Window this should be your choice.
The ExtendedPanel is written entirely on the
Server and have no "custom JavaScript" but is
rather composed by combining other widgets
like Panel, ImageButton and so on together
to form a complex Ajax Control without
having to write JavaScript at all to accomplish
it. The ExtendedPanel is a VERY good example of
how to create your own Extension Widgets without
having to write JavaScript yourself.

The Accordion is completely rewritten using

ExtendedPanels and is now written entirely
as a Server-Side WebControl. In fact the
Accordion is now litle more than a collection
of ExtendedPanels grouped together with a
little bit of Server-Side logic applied.
BREAKING CHANGE!
If you are using the old Accordion you might
have to make some small changes to your code
since the API has changed in addition to that
the skins for it have changed.

The Window is now rendered using a complete

new DOM/HTML model. The new Window is now
rendered completely without the use of HTML
tables which means first of all that it will
be far easier to skin. Also the Window is
completely re-written from scratch which
gives it a FAR more stable running environment
and it should be far easier to extend.
BREAKING CHANGE!
If you have existing custom skins for your
Window widgets you might need to make changes
to those. We do however believe that the new
Window DOM/HTML model is far superior and
will in the long run give you advantages to
great to ignore.

New Widget; Slider Control.

The Gaia Ajax Slider Control is a 100%
server-side written Control made mostly as an
example of how you can easily write complex
server-side controls yourself. But also is a
valuable addition to our Control Suite.

Window now "appears" when displayed on the

client which makes for a smoother experience
for users.

We have moved several of our Widget around and

put them into the "Extensions" project since
many of them baturally "belong" there.
This makes it very easy for you to only use
the "core parts" of Gaia if you wish and
keep your codebase small, slick and
non-bloated for features you don´t use.
BREAKING CHANGE!!
If you get "gaia:SomeWidgetXXX" exceptions
while running, then just replace the "gaia:"
part with "ext:" and make sure you´re
importing the "Extensions" project.

All EventArgs classes are now MOVED into

the widget/aspect that fires them for
consistency.
BREAKING CHANGE!
This will break your code, but is important
to do to keep the consistancy and ease of use
of the library as its complexity increases.

AspectDraggable now has an "id" property

which will be passed into the AspectDroppable
Event handler if item is dropped which makes
it far easier to find back to which item
was dropped if an AspectDraggable is dropped
into an AspectDroppable widget.

You now have access to the Width and Height

of the Viewport on the client from the server
which might be very useful for percentage
positioning.

New Widget; Calendar Widget which is a "static"

calendar you can use to display dates or let
users pick dates from.

DateTimePicker is completely re-created by

composing other widgets together like for
instance the Calendar. The DOM structure for
the DateTimePicker should be far more flexible
and easy to skin. Also it has got support for
localization in any local you want without
having to reside to JavaScript.

New skin called "Gaiax" which have the same look

and feel for every widget we have which should make
it far easier to create a uniform look and feel
for your application.

We´ve revised our Gaia Commercial License.

The new name is Gaia Proprietary License

We´ve upgraded our GPL license to use GPL version 3

which first of all gives you a lot more compliance
towards other FOSS licenses like for instance the
Apache license etc. Secondly it keeps us "in track"
with time since it´s the new license published by
Free Software Foundation.

We´ve completely re-written the designer (WYSIWYG)

experience for Gaia which now should almost reflect
a perfect match for the design time experience while
developing Gaia in Visual Studio.

A LOT of the internals of the library are now

completely re-written from scratch with a FAR better
code-base and code model. This is expecially visible
if you need to "dig in" to the "core" of the library
and do changes yourself or you need to create extension
widgets yourself which now is orders of magnitudes
easier to do than previously.

You can now write Ajax Widgets without having to

even TOUCH JavaScript yourself. In fact several of
our current Ajax Widgets are now completely written in
our server-side code model without resorting to
JavaScript at all by simply composing other existing
Ajax Widgets together. This should have made Gaia
by orders of magnitudes easier to extend.

New license for component developers. We now have

a "component developer license" which enables people
to use Gaia for free to develop extension components
on top of Gaia. We strongly believe in Quid Pro Quo
and that component developers helps our community by
adding value is obvious. We´ve now got a path for
those people to use Gaia without having to pay us
any money at all.

Most Gaia Samples now scores more than 65 in YSlow

and some of the more extreme samples even scores
more than 70 in YSlow which is the best we are aware
of in the entire Ajax industry. This is due to
changes in Skins, DOM structure and internal logic
of widgets in Gaia. This should optimize the
experience for your users a LOT since your
applications will feel far more responsive for your
users. It also reduces the bandwidth usage of your
Gaia applications by FAR and makes Gaia scale far
better than previously. Load time of some of our
samples are reduced to fractions of what they
previously where.

New skins structure in samples which makes it

far easier to take the existing skins and embed
into your own applications.

Most of our widgets now have a completely different

DOM structure which makes them far more efficient
to use and far more easy to skin. In addition we´re
now almost 100% accessible and we are as of the Glory
release 100% XHTML compliant!
BREAKING CHANGE!
Will break several places in your existing
applications in addition to that if you´ve written
skins yourself you will have to modify those skins
quite significantly to get the "Glory ready".

New Widget; ExtendedButton.

An ExtendedButton is a button HTML control which
have some very nice DOM eye-candy wrapping it and
some very interesting features which makes it far
more pleasent to the eye than "just a pure button".

AutoCompleter re-written from scratch.

The AutoCompleter is completely re-written from
scratch and it now have support for having any
Control as elements inside of it including images,
buttons, links and whatever you wish.

New Aspect; AspectGeneric.

AspectGeneric is an aspect for catching "generic"
DOM events on elements you wish. This included
Focus, Blur and several other aspects which can
be catched in a "generic" handle.

Window re-written from scratch.

Window is now a completely re-written server control
meaning it is very easy to extend and add up your
own functionality to. Also it is a far more "robust"
model which also have the positive side-effect that
it significantly reduces the bandwidth usage when
consuming Windows.

New Aspect; AspectObscurer.

Since we´ve re-written our Ajax Window completely
we needed several aspects ourselves in order to
do this. AspectObscurer is one of those. It will
basically make ANY widget "modal" which means
you can have Modal Panels, Windows, DateTimePickers
and virtually anything you can dream about can be
"modal".

New parameter to AspectClickable which is an

"expression" for advanced users which must
evaluate to true in order for the click event
to raise a server-callback. See example usage
in Window.cs at AspectClickable usage.

All EventArgs classes which are specific for

widgets are now MOVED into the widget they
are specific for as "nested classes". If you
get weird bugs for Event Handlers or EventArgs
classes not existing when building your solution
then this is probably the cause.
BREAKING CHANGE!!

Added up "handle" support for AspectResizable

which means you can now resize a widget from
a specific DOM element (or Control)

Added up support for "SibblingElement" in

AspectResizable which ALSO will be resized
with the exact same delta as the resizing
widget.

Removed the ForceAnUpdate method on

"Listible controls" which includes ListBox,
RadioButtonList, CheckBoxList and DropDownList.
Gaia is now automagically tracking the state of
ListItems for all "Listible Controls" which means
that it´s much easier to add, remove and modify
the collection of ListItems for these controls.
If you get weird compiler bugs with ForceAnUpdate
not defined for any of those controls, then just
remove the ForceAnUpdate call in your code.

New class AtomicInvoker which helps you to

increase the level of cohesion in your own
code if used correctly due to having a very
nice usage of the IDisposable pattern.
With this class you can couple two methods,
typically a "initialize method" and a
"de-initialize method" together and have
a guarantee of both of them being executed
in "pars" within a scope due to exploiting
the "using" or "IDisposable" pattern.
Basically gives deterministic capabilities
through using delegates and IDisposable to
C#.

Window now has a property for animating

its appearance. If set to something else than
0 it will spend that amount of milliseconds
fading into view when shown.

Removed ResizedEventArgs for AspectResizable

and WindowResizedEventArgs for Window, they
provided redundant information (width and height),
that can be found using the Widget´s Style
BREAKING CHANGE!

Added several new constructors for AspectResizable.

Removed Columns and Rows from InPlaceEdit, now it relies

only on Width and Height. BREAKING CHANGE!

In InPlaceEdit if in SingleLine mode and no Width

is specified, the edit TextBox size will be adjusted
to fit the Text. If Width is specified, it is used
instead. If in MultiLine mode, Width and Height are used.

In InPlaceEdit, SingleLine is now true by default

and HasButtons is false by default, since this is
the way that InPlaceEdit is used most of the time.

Window can now be opened in Maximized and

Minimized state. Not only that but Window will
also "remember" its state when closed and re-opened.
This means that if you open a Window, then maximize
it and close it to reopen it again, the window
will reopen Maximized.

Added support for "OpacityWhenMoved" property on

Window which defines how much transparency a
Window will have when moved.

You can now allow or disallow TreeViewItems

or entire TreeViews explicitly to be animated
when expanded and collapsed. This works so
that if the AnimateToggling property is set
for a TreeViewItem the TreeViewItem value
will be used. Otherwise the default setting
for the TreeView will be used. The default
value for both TreeViewItems and the TreeView
is to ALLOW animation of TreeViewItems.

All of our samples are now 100% XHTML 1.0

compliant.

You can now set the Color of the obscured

area of a Modal Window.

You can now set the amount of transparency

for a Modal Window.

Window no longer has the Modal property though

the same effect can easily be done by adding
the AspectModal to the Window. AspectModal
can in fact make anything modal in addition
to setting the color of the obscurer, amount
of transparency etc. So it should be far more
flexible though at the cost of rendering
slightly in-compatible changes.
BREAKING CHANGE!!
This means you need to change every place
you´re using the Modal property of your
Windows.

BUG-FIXES

Fixed a bug in AspectScrollable, which prevented it from working in some cases.

Also both horizontal and vertical scrollbars can be used without
redundant event generation when raiseAtEdge is set to "true".

Fixed AspectResizeable issues with resizable control hierarchies.

Fixed resize mode detection problems.

Fixed a bug in AspectKey, which was preventing it from being usable at all.

Fixed AspectClickable event bubbling issues. Now by-default "onclick" event

won´t bubble up. In special cases bubbling can be enabled by
creating a derived class from AspectClickable.

Fixed a very severe bug which makes it impossible to

set values for any Gaia controls in Ajax Callbacks
in Page_Load or any place before the OnLoad event
of the page. No controls could previously have
their values changed in either Page_Load, Page_Init
or any place before Page_Load. This is now fixed so
that it now works mimicking ASP.NET normal "postbacks"
100%.

Fixed threading problem with setup where background

thread attempts to update controls in GUI.

Because of a bug in prototype it became impossible

in Tranquility to set z-index and other styles
containing a "-" in Ajax Callbacks. This bug is
now fixed!

Fixed a bug in AspectResizable which made the

destructor for the resizable cast an exception and
show a dialog.

Fixed a bug in AspectResizable that didn´t make the

style["width"] and "height" properties update when
widget was resized.

Fixed a bug in AspectResizable which made the widget

be resized even when mouse was far outside of the
widget but close to one of the axis of the borders.

Fixed a bug in RichEdit which made it impossible to

use widgets which demands "focus" to manipulate the
selected text on the server. The problem is that when
another widget is clicked the RichEdit would loose
focus and then the "selected range" would be deleted
from the RichEdit control in IE. Then when you came
to the server there was always "nothing selected" in
the RichEdit if whatever brought you to the server
demanded that the user CLICKED something on the
page. This is now fixed by storing the "selected range"
when the RichEdit looses focus and then submitting
the STORED selected range to the server when an
ajax request is raised.

Changed the wrapper element for the TextBox of the

InPlaceEdit to be a SPAN which means it doesn´t
"jump" around because of being block-level element
and the span that normally displays the text is not.

Also changed so that the "Rows" property of the

InPlaceEdit means "width-in-pixel" if it is set
and the InPlaceEdit is in "SingleLine" edit mode.

All the Attributes of the AttributeCollection

of all of our widgets are now rendering which
means that you can set any attribute
programatically from your code and it will work
with Gaia.

Fixed a bug which makes it impossible to have "´"

as part of the URL back to the website in Gaia
Applications.

Fixed a bug in AspectDroppable that made it

impossible to include AspectDroppable in
widgets which was being shown (set visible)
in Ajax Callbacks.

Fixed a bug that if the user navigates away

from the page when there´s an "open" Ajax
request an error will be shown.

Fixed a SEVERE bug on ALL Container Widgets

which made it impossible to "move them around"
in e.g. AspectDraggable without running into
weird and obscure ViewState bugs that would
throw exceptions.

ViewState is now loaded by ID instead of by

index which was the case previously. This has
fixed a TON of bugs in regards to especially
Dynamically created controls and especially
if those controls (and parent controls) are
being "moved around" with e.g. AspectDraggable
and similar constructs in Ajax Callbacks.
This have the negative sideeffect though that
you MUST give ALL your controls (which are
supposed to be "moved around") an explicit
ID property. If you get "weird" JavaScript
bugs in callbacks when "moving widgets" around
than this is the probable cause. Make sure
you give ALL your widgets an explicit ID
property. At least the ones which you want
to move around on the page in the Control
hierarchy.

Fixed a bug in TextBox which on Safari made

it impossible to trap backspace and some
other "system key strokes" events if
KeyChangeEvents was set to true.

Fixed a bug with InPlaceEdit which in

Opera and Safari would cause "some random"
Button being clicked (the default one) when
InPlaceEdit was in SingleLine edit mode and
user clicked Carriage Return to "finish"
editing.

Fixed a bug with InPlaceEdit which in Opera

the first time the InPlaceEdit field was
being edited it wouldn´t select all "current"
text in the TextBox.

Added support for having "empty text" in

InPlaceEdit by typing in " " as the
Text property which then will display as
"empty text" when InPlaceEdit is clicked
to edit the text.

All though the "JS core" of Gaia has been

set to being refactored in our NEXT release
we have done several changes to it to
further SERIOUSLY stabilize it so the it
should be experienced as far more stable on
all browsers than Tranquility was.

The DateTimcPicker is not relying on the

Format being set before the Value is being
set. In your .ASPX file you must now define
the Value property as an ISO DateTime string
meaning; "yyyy.MM.dd HH:mm" and then the
Format property is only being used for
displaying the Value in the TextBox back
to the user. This is a breaking change
though we believe it to be too important
to not fix.
BREAKING CHANGE!!

The AutoCompleter doesn´t "jump around"

the scroll position of the page anymore.

The Glory release is by far the greatest release
we in Gaiaware ever have had on our Gaia Ajax
Widgets. We hope everyone should be able to find
features they like, if it is the ability to have
checkboxes inside of TreeViewItems or the easiness
you can yourself skins Gaia Widgets in or the
extreme optimizations we´ve added to Gaia.
However this comes with the cost of not being
100% backwards compatible which we hope our existing
customers can be understanding about all though
it breaks your existing code unfortunately.
We hope you can all see that these changes was
necessary and that we´ve tried to be as backwards
compatible as possible and at the same time still
try to move the library forward a giant leap into
the future.
If you are very close to a current release of
one of your Gaia applications it might be better
to wait to upgrade since you will experience
several places where your current code base will
break in regards to Glory.
Some of the things we´ve done are also 100%
rewrites.
Take especially notice if you´re consuming
DateTimePickers, TreeView, Viewport, AutoCompleter
or Menu widgets in your application, then the
cost of upgrading will be quite high since most
of this logic in these widgets is completely
re-written now.