Tuesday, March 22, 2011

Subverting the JCP - Why?

Just read this post by Java lead Mark Reinhold in which he says that

It's therefore time to define a simple process for collecting, sorting,
reviewing, and prioritizing proposals and plans for new features, for
JDK 8 and for later releases.

Some essential requirements (not in priority order):

- As lightweight as possible.

- Simple mechanics.

- Version-controlled, so that changes can be tracked.

- Open to all committers, with transparent decision-making.

- The basic format should not be too different from (a simplified
form of) the old Sun "one-pager" template [1], with which many
are already familiar.

- An approved proposal should be able to serve as the authoritative
source of the summary and reference information needed for related
documents such as the release feature list [2] and the Platform
Umbrella JSR specification [3].

[emphasis mine]

A big problem I've seen with the JCP is this desire to use it as a rubber-stamp for JavaSE rather than, as most other JSRs including the JEE ones are, an actual debate on what needs to be done. I agree with soliciting feedback from a wide community and making that open (I'd argue that the JCP should be open ala OASIS) but I really don't get why we need a proposal mechanism outside of the JCP to manage this unless the ambition is to purely manage it from an Oracle/OpenJDK perspective rather than as an actual part of the Java Community Process. The proposed approach smacks of the pre-JCP days where Sun solicited feedback and controlled the process and which the JCP was set up to change.

I'm depressed, I'd like to see the JCP successful and the voices listened to not a new process created outside of a standards group and controlled by the leader of the JSR who will then present it to the JSR team as a fait accompli which is exactly what led to the debacle with JAX-WS and the problems that it delivered.

Thursday, March 17, 2011

Announcing the HTML5 dynamic layout manager

One of the challenges I've found with the latest HTML 5 frameworks is that they require a significant amount of hand-coding and when looking at things like proportional layouts it can get pretty tricky if you need to do complex layouts. Now things like Buttons and the like are of course there and all the basic primitives but what I'm really after is something where I can do some complex layouts and set stuff like the piece of the page with initial focus.

From a mashup perspective I want to be able to nest these layouts so I can create pages out of various sub-fragments and enable people to quickly create "trees" of independently created layouts, ideally enabling all of this to be done using a visual building tool.

So I looked around and I'd now like to announce 5Form, probably the most powerful layout manager available today and one designed for the mashup challenges and complex interfaces that the web requires. Proportional layouts, inter-widget layout dependencies, dynamic resizing and more are all automatically handled by this new powerful layout manager

NAME

5Form - The HTML5 dynamic layout manager

5Form is a dynamic HTML5 container with no input semantics of its own.
Constraints are placed on children of the 5Form to define attachments
for each of the child's four sides. These attachments can be to the
5Form, to another child widget or gadget, to a relative position within
the 5Form, or to the initial position of the child. The attachments
determine the layout behavior of the 5Form when resizing occurs.

The default value for 5NinitialFocus
is the value of 5NdefaultButton.

Following are some important considerations in using a 5Form:


  • Every child must have an attachment on either the left or the
    right. If initialization or 5SetValues leaves a
    widget without such an attachment, the result depends upon the value
    of 5NrubberPositioning.

    If 5NrubberPositioning is
    False, the child is given an 5NleftAttachment of
    5ATTACH_FORM and an 5NleftOffset equal to its current
    x value.

    If 5NrubberPositioning is
    True, the child is given an 5NleftAttachment of
    5ATTACH_POSITION and an 5NleftPosition proportional to
    the current x value divided by the width of the 5Form.

    In either case, if the child has not been previously given an
    x value, its x value is taken to be 0, which places
    the child at the left side of the 5Form.

  • If you want to create a child without any attachments, and then
    later (e.g., after creating and managing it, but before realizing it)
    give it a right attachment via XtSetValues, you must
    set its 5NleftAttachment to
    5ATTACH_NONE at the same time.
  • The 5Nresizable
    resource controls only whether a geometry request by the child will be
    granted. It has no effect on whether the child's size can be changed
    because of changes in geometry of the 5Form or of other children.
  • Every child has a preferred width, based on geometry requests
    it makes (whether they are granted or not).
  • If a child has attachments on both the left and the right
    sides, its size is completely controlled by the 5Form. It can be
    shrunk below its preferred width or enlarged above it, if necessary,
    due to other constraints. In addition, the child's geometry requests
    to change its own width may be refused.
  • If a child has attachments on only its left or right side, it
    will always be at its preferred width (if resizable, otherwise at is
    current width). This may cause it to be clipped by the 5Form or by
    other children.
  • If a child's left (or right) attachment is set to
    5ATTACH_SELF, its corresponding left (or right)
    offset is forced to 0. The attachment is then changed to
    5ATTACH_POSITION, with a position that corresponds
    to x value of the child's left (or right) edge. To fix the
    position of a side at a specific x value use
    5ATTACH_FORM or
    5ATTACH_OPPOSITE_FORM with the x value as
    the left (or right) offset.
  • Unmapping a child has no effect on the 5Form except that the
    child is not mapped.

  • Unmanaging a child unmaps it. If no other child is attached to
    it, or if all children attached to it and all children recursively
    attached to them are also all unmanaged, all of those children are
    treated as if they did not exist in determining the size of the 5Form.
  • When using XtSetValues to change the
    5Nx resource of a
    child, you must simultaneously set its left attachment to either
    5ATTACH_SELF or 5ATTACH_NONE.
    Otherwise, the request is not granted. If 5Nresizable is False, the request
    is granted only if the child's size can remain the same.
  • A left (or right) attachment of
    5ATTACH_WIDGET, where 5NleftWidget (or 5NrightWidget) is NULL, acts like
    an attachment of 5ATTACH_FORM.
  • If an attachment is made to a widget that is not a child of the
    Form, but an ancestor of the widget is a child of the 5Form, the
    attachment is made to the ancestor.

All these considerations are true of top and bottom attachments as
well, with top acting like left, bottom acting like right, y
acting like x, and height acting like width.

Resources


The following table defines a set of widget resources used by the
programmer to specify data. The programmer can also set the resource
values for the inherited classes to set attributes for this widget.
The codes in the access column indicate if the given
resource can be set at creation time (C), set by using
5SetValues (S), retrieved by using
5GetValues (G), or is not applicable (N/A).


5Form Resource Set
Name Class Type Default Access
5NfractionBase 5CMaxValue int 100 CSG
5NhorizontalSpacing 5CSpacing Dimension 0 CSG
5NrubberPositioning 5CRubberPositioning Boolean False CSG
5NverticalSpacing 5CSpacing Dimension 0 CSG


5NfractionBase
Specifies the
denominator used in calculating the relative position of a child
widget using 5ATTACH_POSITION constraints. The
value must not be 0.

If the value of a child's 5NleftAttachment (or
5NrightAttachment)
is 5ATTACH_POSITION, the position of the left (or
right) side of the child is relative to the left side of the 5Form and
is a fraction of the width of the 5Form. This fraction is the value of
the child's 5NleftPosition (or 5NrightPosition) resource
divided by the value of the 5Form's 5NfractionBase.

If the value of a child's 5NtopAttachment (or 5NbottomAttachment) is
5ATTACH_POSITION, the position of the top (or
bottom) side of the child is relative to the top side of the 5Form and
is a fraction of the height of the 5Form. This fraction is the value
of the child's 5NtopPosition (or 5NbottomPosition) resource
divided by the value of the 5Form's 5NfractionBase.

5NhorizontalSpacing
Specifies the offset for right and left attachments. This
resource is only used if no offset resource is specified (when
attaching to a widget), or if no margin resource is specified (when
attaching to the 5Form).
5NrubberPositioning
Indicates the default near (left) and top attachments for a
child of the 5Form. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.)

The default left attachment is applied whenever initialization or
XtSetValues leaves the child without either a left or
right attachment. The default top attachment is applied whenever
initialization or XtSetValues leaves the child
without either a top or bottom attachment.

If this Boolean resource is set to False, 5NleftAttachment and
5NtopAttachment
default to 5ATTACH_FORM, 5NleftOffset defaults to the
current x value of the left side of the child, and 5NtopOffset defaults to the current
y value of the child. The effect is to position the child
according to its absolute distance from the left or top side of the
Form.

If this resource is set to True, 5NleftAttachment and
5NtopAttachment
default to 5ATTACH_POSITION, 5NleftPosition defaults to a
value proportional to the current x value of the left side of
the child divided by the width of the 5Form, and 5NtopPosition defaults to a value
proportional to the current y value of the child divided by
the height of the 5Form. The effect is to position the child relative
to the left or top side of the 5Form and in proportion to the width or
height of the 5Form.

5NverticalSpacing
Specifies the offset for top and bottom attachments. This
resource is only used if no offset resource is specified (when
attaching to a widget), or if no margin resource is specified (when
attaching to the 5Form).


5Form Constraint Resource Set
Name Class Type Default Access
5NbottomAttachment 5CAttachment unsigned char 5ATTACH_NONE CSG
5NbottomOffset 5COffset int 0 CSG
5NbottomPosition 5CAttachment int 0 CSG
5NbottomWidget 5CWidget Widget NULL CSG
5NleftAttachment 5CAttachment unsigned char 5ATTACH_NONE CSG
5NleftOffset 5COffset int 0 CSG
5NleftPosition 5CAttachment int 0 CSG
5NleftWidget 5CWidget Widget NULL CSG
5Nresizable 5CBoolean Boolean True CSG
5NrightAttachment 5CAttachment unsigned char 5ATTACH_NONE CSG
5NrightOffset 5COffset int 0 CSG
5NrightPosition 5CAttachment int 0 CSG
5NrightWidget 5CWidget Widget NULL CSG
5NtopAttachment 5CAttachment unsigned char 5ATTACH_NONE CSG
5NtopOffset 5COffset int 0 CSG
5NtopPosition 5CAttachment int 0 CSG
5NtopWidget 5CWidget Widget NULL CSG


5NbottomAttachment
Specifies attachment of the bottom side of the child. It can
have the following values:

  • 5ATTACH_NONE - Do not attach the bottom side
    of the child.
  • 5ATTACH_FORM - Attach the bottom side of the
    child to the bottom side of the 5Form.
  • 5ATTACH_OPPOSITE_FORM - Attach the bottom
    side of the child to the top side of the 5Form. 5NbottomOffset can be used to
    determine the visibility of the child.
  • 5ATTACH_WIDGET - Attach the bottom side of
    the child to the top side of the widget or gadget specified in the
    5NbottomWidget resource. If
    5NbottomWidget is NULL,
    5ATTACH_WIDGET is replaced by
    5ATTACH_FORM, and the child is attached to the
    bottom side of the 5Form.
  • 5ATTACH_OPPOSITE_WIDGET - Attach the bottom
    side of the child to the bottom side of the widget or gadget specified
    in the 5NbottomWidget
    resource.
  • 5ATTACH_POSITION - Attach the bottom side of
    the child to a position that is relative to the top side of the 5Form
    and in proportion to the height of the 5Form. This position is
    determined by the 5NbottomPosition and
    5NfractionBase
    resources.
  • 5ATTACH_SELF - Attach the bottom side of the
    child to a position that is proportional to the current y
    value of the bottom of the child divided by the height of the 5Form.
    This position is determined by the 5NbottomPosition and
    5NfractionBase
    resources. 5NbottomPosition is set to a
    value proportional to the current y value of the bottom of
    the child divided by the height of the 5Form.

5NbottomOffset
Specifies the constant offset between the bottom side of the
child and the object to which it is attached. The relationship
established remains, regardless of any resizing operations that occur.
When this resource is explicitly set, the value of 5NverticalSpacing is ignored.
5NbottomPosition
This resource is used to determine the position of the bottom
side of the child when the child's 5NbottomAttachment is set to
5ATTACH_POSITION. In this case the position of the
bottom side of the child is relative to the top side of the 5Form and
is a fraction of the height of the 5Form. This fraction is the value
of the child's 5NbottomPosition resource divided by
the value of the 5Form's 5NfractionBase. For example, if
the child's 5NbottomPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's height is 200, the position of the bottom side of
the child is 100.
5NbottomWidget
Specifies the widget or gadget to which the bottom side of the
child is attached. This resource is used if 5NbottomAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5NleftAttachment
Specifies attachment of the near (left) side of the child.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) It can have the following values:

  • 5ATTACH_NONE - Do not attach the left side of
    the child. If 5NrightAttachment is also
    5ATTACH_NONE, this value is ignored and the child is
    given a default left attachment.
  • 5ATTACH_FORM - Attach the left side of the
    child to the left side of the 5Form.
  • 5ATTACH_OPPOSITE_FORM - Attach the left side
    of the child to the right side of the 5Form. 5NleftOffset can be used to
    determine the visibility of the child.
  • 5ATTACH_WIDGET - Attach the left side of the
    child to the right side of the widget or gadget specified in the
    5NleftWidget resource. If
    5NleftWidget is NULL,
    5ATTACH_WIDGET is replaced by
    5ATTACH_FORM, and the child is attached to the left
    side of the 5Form.
  • 5ATTACH_OPPOSITE_WIDGET - Attach the left
    side of the child to the left side of the widget or gadget specified
    in the 5NleftWidget resource.
  • 5ATTACH_POSITION - Attach the left side of
    the child to a position that is relative to the left side of the 5Form
    and in proportion to the width of the 5Form. This position is
    determined by the 5NleftPosition and 5NfractionBase resources.
  • 5ATTACH_SELF - Attach the left side of the
    child to a position that is proportional to the current x
    value of the left side of the child divided by the width of the 5Form.
    This position is determined by the 5NleftPosition and 5NfractionBase resources.
    5NleftPosition is set
    to a value proportional to the current x value of the left
    side of the child divided by the width of the 5Form.

5NleftOffset
Specifies the constant offset between the near (left) side of
the child and the object to which it is attached.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) The relationship established remains, regardless of any
resizing operations that occur. When this resource is explicitly set,
the value of 5NhorizontalSpacing is
ignored.
5NleftPosition
This resource is used to determine the position of the near
(left) side of the child when the child's 5NleftAttachment is set to
5ATTACH_POSITION. (Note: Whether
this resource actually applies to the left or right side of the child
and its attachment may depend on the value of the 5NstringDirection
resource.)

In this case the position of the left side of the child is relative
to the left side of the 5Form and is a fraction of the width of the
Form. This fraction is the value of the child's
5NleftPosition resource divided by the value of the
Form's 5NfractionBase. For example, if
the child's 5NleftPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's width is 200, the position of the left side of the
child is 100.

5NleftWidget
Specifies the widget or gadget to which the near (left) side of
the child is attached. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.) This resource is used if 5NleftAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5Nresizable
This Boolean resource specifies whether or not a child's
request for a new size is (conditionally) granted by the 5Form. If
this resource is set to True the request is granted if possible. If
this resource is set to False the request is always refused.

If a child has both left and right attachments, its width is
completely controlled by the 5Form, regardless of the value of the
child's 5Nresizable resource. If a child has a left
or right attachment but not both, the child's 5Nwidth is used in setting its width if
the value of the child's 5Nresizable resource is
True. These conditions are also true for top and bottom attachments,
with height acting like width.

5NrightAttachment
Specifies attachment of the far (right) side of the child.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection
resource.) It can have the following values:

  • 5ATTACH_NONE - Do not attach the right side
    of the child.
  • 5ATTACH_FORM - Attach the right side of the
    child to the right side of the 5Form.
  • 5ATTACH_OPPOSITE_FORM - Attach the right side
    of the child to the left side of the 5Form. 5NrightOffset can be used to
    determine the visibility of the child.
  • 5ATTACH_WIDGET - Attach the right side of the
    child to the left side of the widget or gadget specified in the
    5NrightWidget resource. If
    5NrightWidget is NULL,
    5ATTACH_WIDGET is replaced by
    5ATTACH_FORM, and the child is attached to the right
    side of the 5Form.
  • 5ATTACH_OPPOSITE_WIDGET - Attach the right
    side of the child to the right side of the widget or gadget specified
    in the 5NrightWidget resource.
  • 5ATTACH_POSITION - Attach the right side of
    the child to a position that is relative to the left side of the 5Form
    and in proportion to the width of the 5Form. This position is
    determined by the 5NrightPosition and 5NfractionBase resources.
  • 5ATTACH_SELF - Attach the right side of the
    child to a position that is proportional to the current x
    value of the right side of the child divided by the width of the 5Form.
    This position is determined by the 5NrightPosition and 5NfractionBase resources.
    5NrightPosition is
    set to a value proportional to the current x value of the
    right side of the child divided by the width of the 5Form.

5NrightOffset
Specifies the constant offset between the far (right) side of
the child and the object to which it is attached.
(Note: Whether this resource actually applies to the
left or right side of the child and its attachment may depend on the
value of the 5NstringDirection resource.)
The relationship established remains, regardless of any resizing
operations that occur. When this resource is explicitly set, the
value of 5NhorizontalSpacing is
ignored.
5NrightPosition
This resource is used to determine the position of the far
(right) side of the child when the child's 5NrightAttachment is set to
5ATTACH_POSITION. (Note: Whether
this resource actually applies to the left or right side of the child
and its attachment may depend on the value of the 5NstringDirection
resource.)

In this case the position of the right side of the child is
relative to the left side of the 5Form and is a fraction of the width
of the 5Form. This fraction is the value of the child's
5NrightPosition resource divided by the value of the
Form's 5NfractionBase. For example, if
the child's 5NrightPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's width is 200, the position of the right side of
the child is 100.

5NrightWidget
Specifies the widget or gadget to which the far (right) side of
the child is attached. (Note: Whether this resource
actually applies to the left or right side of the child and its
attachment may depend on the value of the 5NstringDirection
resource.) This resource is used if 5NrightAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.

5NtopAttachment
Specifies attachment of the top side of the child. It can have
following values:

  • 5ATTACH_NONE - Do not attach the top side of
    the child. If 5NbottomAttachment is also
    5ATTACH_NONE, this value is ignored and the child is
    given a default top attachment.
  • 5ATTACH_FORM - Attach the top side of the
    child to the top side of the 5Form.
  • 5ATTACH_OPPOSITE_FORM - Attach the top side
    of the child to the bottom side of the 5Form. 5NtopOffset can be used to
    determine the visibility of the child.
  • 5ATTACH_WIDGET - Attach the top side of the
    child to the bottom side of the widget or gadget specified in the
    5NtopWidget resource. If
    5NtopWidget is NULL,
    5ATTACH_WIDGET is replaced by
    5ATTACH_FORM, and the child is attached to the top
    side of the 5Form.
  • 5ATTACH_OPPOSITE_WIDGET - Attach the top side
    of the child to the top side of the widget or gadget specified in the
    5NtopWidget resource.
  • 5ATTACH_POSITION - Attach the top side of the
    child to a position that is relative to the top side of the 5Form and
    in proportion to the height of the 5Form. This position is determined
    by the 5NtopPosition and
    5NfractionBase resources.
  • 5ATTACH_SELF - Attach the top side of the
    child to a position that is proportional to the current y
    value of the child divided by the height of the 5Form. This position
    is determined by the 5NtopPosition and 5NfractionBase resources.
    5NtopPosition is set
    to a value proportional to the current y value of the child
    divided by the height of the 5Form.

5NtopOffset
Specifies the constant offset between the top side of the child
and the object to which it is attached. The relationship established
remains, regardless of any resizing operations that occur. When this
resource is explicitly set, the value of 5NverticalSpacing is ignored.
5NtopPosition
This resource is used to determine the position of the top side
of the child when the child's 5NtopAttachment is set to
5ATTACH_POSITION. In this case the position of the
top side of the child is relative to the top side of the 5Form and is a
fraction of the height of the 5Form. This fraction is the value of the
child's 5NtopPosition resource divided by the value
of the 5Form's 5NfractionBase. For example, if
the child's 5NtopPosition is 50, the 5Form's
5NfractionBase is
100, and the 5Form's height is 200, the position of the top side of the
child is 100.
5NtopWidget
Specifies the widget or gadget to which the top side of the
child is attached. This resource is used if 5NtopAttachment is set to
either 5ATTACH_WIDGET or
5ATTACH_OPPOSITE_WIDGET.

A string-to-widget resource converter is automatically installed
for use with this resource. With this converter, the widget that is
to be the value of the resource must exist at the time the widget that
has the resource is created.


Additional Resources



5BulletinBoard Resource Set
Name Class Type Default Access
5NallowOverlap 5CAllowOverlap Boolean True CSG
5NautoUnmanage 5CAutoUnmanage Boolean True CG
5NbuttonFontList 5CButtonFontList 5FontList dynamic CSG
5NcancelButton 5CWidget Widget NULL SG
5NdefaultButton 5CWidget Widget NULL SG
5NdefaultPosition 5CDefaultPosition Boolean True CSG
5NdialogStyle 5CDialogStyle unsigned char dynamic CSG
5NdialogTitle 5CDialogTitle 5String NULL CSG
5NfocusCallback 5CCallback XtCallbackList NULL C
5NlabelFontList 5CLabelFontList 5FontList dynamic CSG
5NmapCallback 5CCallback XtCallbackList NULL C
5NmarginHeight 5CMarginHeight Dimension 0 CSG
5NmarginWidth 5CMarginWidth Dimension 0 CSG
5NnoResize 5CNoResize Boolean False CSG
5NresizePolicy 5CResizePolicy unsigned char 5RESIZE_ANY CSG
5NshadowType 5CShadowType unsigned char 5SHADOW_OUT CSG
5NtextFontList 5CTextFontList 5FontList dynamic CSG
5NtextTranslations 5CTranslations XtTranslations NULL C
5NunmapCallback 5CCallback XtCallbackList NULL C


5Manager Resource Set
Name Class Type Default Access
5NbottomShadowColor 5CBottomShadowColor Pixel dynamic CSG
5NbottomShadowPixmap 5CBottomShadowPixmap Pixmap 5UNSPECIFIED_PIXMAP CSG
5Nforeground 5CForeground Pixel dynamic CSG
5NhelpCallback 5CCallback XtCallbackList NULL C
5NhighlightColor 5CHighlightColor Pixel dynamic CSG
5NhighlightPixmap 5CHighlightPixmap Pixmap dynamic CSG
5NinitialFocus 5CInitialFocus Widget dynamic CSG
5NnavigationType 5CNavigationType 5NavigationType 5TAB_GROUP CSG
5NshadowThickness 5CShadowThickness Dimension dynamic CSG
5NstringDirection 5CStringDirection 5StringDirection dynamic CG
5NtopShadowColor 5CTopShadowColor Pixel dynamic CSG
5NtopShadowPixmap 5CTopShadowPixmap Pixmap dynamic CSG
5NtraversalOn 5CTraversalOn Boolean True CSG
5NunitType 5CUnitType unsigned char dynamic CSG
5NuserData 5CUserData XtPointer NULL CSG


Composite Resource Set
Name Class Type Default Access
5Nchildren 5CReadOnly WidgetList NULL G
5NinsertPosition 5CInsertPosition XtOrderProc NULL CSG
5NnumChildren 5CReadOnly Cardinal 0 G


Core Resource Set
Name Class Type Default Access
5Naccelerators 5CAccelerators XtAccelerators dynamic N/A
5NancestorSensitive 5CSensitive Boolean dynamic G
5Nbackground 5CBackground Pixel dynamic CSG
5NbackgroundPixmap 5CPixmap Pixmap 5UNSPECIFIED_PIXMAP CSG
5NborderColor 5CBorderColor Pixel XtDefaultForeground CSG
5NborderPixmap 5CPixmap Pixmap 5UNSPECIFIED_PIXMAP CSG
5NborderWidth 5CBorderWidth Dimension 0 CSG
5Ncolormap 5CColormap Colormap dynamic CG
5Ndepth 5CDepth int dynamic CG
5NdestroyCallback 5CCallback XtCallbackList NULL C
5Nheight 5CHeight Dimension dynamic CSG
5NinitialResourcesPersistent 5CInitialResourcesPersistent Boolean True C
5NmappedWhenManaged 5CMappedWhenManaged Boolean True CSG
5Nsensitive 5CSensitive Boolean True CSG
5Ntranslations 5CTranslations XtTranslations dynamic CSG
5Nwidth 5CWidth Dimension dynamic CSG
5Nx 5CPosition Position 0 CSG
5Ny 5CPosition Position 0 CSG




Now if you've made it this far and not realised, this isn't actually a new widget for HTML5 its actually just a widget from the late 1980s called XmForm which remains the most powerful layout manager I've personally ever come across in a widget tool kit.

Why this silly post then? Well its sort of to make the point that client side frameworks are a "solved problem" and rather than heading out are re-inventing wheels we should think about what is actually new.

So the differences with XWindows and HTML5 are what? Putting aside the syntax and URIs via XAtom et al what are the real architectural differences from a client side framework perspective? I'd argue that the difference is sophistication. HTML5 is in its infancy but should we expect widget sets and libraries to be created, layout managers and other elements... of course we should.

So rather than creating all this stuff from scratch lets go back to the future to when client side interfaces had to be rich and had to handle huge complexities and learn from those frameworks rather than thinking that client side development is a new challenge for IT that needs lots of debate.

What ever happens it should be based around the principles of HMVC (Hierarchical Model View Controller) and should learn the lessons of GTK, Swing, Motif, X-Windows and the like.

Lets port XmForm to HTML5 rather than try and create everything again from the base up.

Technorati Tags: ,

Tuesday, March 15, 2011

There is no HR/Business divide, which is why its IT's fault

The IT/Business divide is something that exists in most businesses I've worked with. I think it comes from a few different drivers, one of which being that IT is often the smartest set of folks in the room academically if not socially. But one piece I can't agree with is that the fault for the divide lies on both sides.

Lets flip away from IT for a moment and concentrate on other "support" parts of the organisation. HR and Finance. These aren't the front-line of the business but they are critical support functions. Now I've regularly heard people in the business moan about Finance being too conservative or too controlling but I've never heard people talk about a Finance/Business divide or that the CFO is disconnected from the business. The perspective might be that Finance has a different view on the current opportunities or issues but not that the business and Finance are disconnected. HR even more so, the HR Director who is disconnected from their business is a fired HR director.

In IT however I've regularly seen CIOs who are disconnected from the business and seen architecture communities who have said classic phrases like "it doesn't matter what the business wants, if we say its not going in, its not going in". IT continues to talk technology rather than business and optimise things (programming languages) that add zero business benefits. IT regularly bleats "The business must realise how important this is" rather than actually working out what is important to the business.

The business/IT divide is the fault of IT because IT doesn't make the effort to communicate the value in the language of the business its like the worst kind of tourist who thinks that shouting louder is better than learning the local language.

Its time for IT to stop looking inwards on optimising wheels and start focusing on how to communicate about IT with the business in their own language.

Technorati Tags: ,

Tuesday, March 08, 2011

MDM, SOA and BPM - making processes simple

BPM is once again a hot topic. It seems several years ago where I said "if you want to get enterprise cash, learn BPEL"... in fact it was 5 years ago! However BPM really hasn't delivered on the promises and that is for three reasons

1) The Promises were too big
2) The implementations were too complex
3) BPEL rapidly became a Visual COBOL approach

Now I've said before that BPM screws up SOA and that SOA makes BPM simple, I'll stick with that and I'll now raise another piece in conjunction with SOA and MDM. This is actually a way to make BPM work more effectively, more simply and reduce the issues around elements such as process [de|]hydration. Namely that if you are in an area where BPM is the best implementation approach for a specific service's capability then using MDM helps to make its implementation simpler as you can work on key exchange rather than on content exchange.

Rather than BPM folks worrying about the schemas and exchange of core information that is left to MDM (where it belongs) and the SOA pieces handles the business domains part to make sure processes have clear boundaries and can be well managed.


Technorati Tags: ,