[
Lists Home |
Date Index |
Thread Index
]
FYI... the xameleon project I started a while back and have since
held back the release while I completely rewrite the foundation of
this library using FXSL and XSLT 2.0 allows you to use one base
foundation (right now its XHTML elements that each have a possible
child element called "style" with subsequent possible children for
each CSS 2.1 property with children and/or attributes to further hold
the names and values of each property for this particular element --
this may be changing to SVG as its base as it is seemingly more
natural to map an SVG-like syntax to XAML and XUL (XUL's proving to be
a real pain in the butt but itll get there eventually) than it is a
XHTML and CSS-based syntax to SVG, XAML, and XUL)
Anyway the point of this post is to point out the fact that there is
definitely recognition in the industry to the fact that the ever
expanding plethora of XML-based declarative languages that abound, at
least conceptually, in our development world these days is probably
doing more damage than it is good, further separating platforms that
actually are extensions to the same base platform (e.g. XUL in Mozilla
and XAML via either Xamlon or Avalon in 90% of the cases run on top of
the same GDI subsystem (or variation thereof) and as such provide just
a slightly different enough syntax to really piss you off and force
you into writing two or three or four versions of basically the same
code base just to appease the various "users" who prefer this or that
or whatever else (I really believe that a good dose of Lithium
"silently" integrated into our water systems would do a world of good
in curing the bi-polar disorder that is the declarative XML GUI
definition language hell we have created for ourselves to now deal
with --
The supposed DLL Hell that was the 90's doesn't even hold a small blue
birthday candle to the dXML Hell we are about to experience in this
industry in this now almost 5 year old new millenium of ours.
Unless...
Again, the point of the "xameleon" project is to try and retain some
sort of sanity by allowing you to build on one dXML language (d
stands for Declarative if your'e wondering what I am refering to with
the little "d") -- most likely SVG eventually for the reasons stated
above, and then use the xameleon engine (powered by Saxon.NET which,
by the way, I'm about 2-3 hours away from either releasing the 8.2
beta 1 build or putting it to bed for the night and picking it up
again tomorrow afternoon to then release tomorrow night instead --
problems with jaxp compatibility stuff is the current and only slow
down at the moment) to output the GENERAL GUI framework for each
desired dXML output. I emphasize general as there are definitely
areas in which are to far apart to do an adequate mapping job and as
such require a bit of hand massaging after the fact... still, a few
hours of massaging code is a lot better than a few weeks of developing
a completely new code base so I think most people will be cool with
it. Theres bound to be a winer here and there but to be honest I
could give a -- wait, better not say that here... ;) I'm sure you get
my point none-the-less ;)
Some screen shots of the older C# based development UI can be seen
here > http://www.x2x2x.org/x2x2x/images/xameleonGUIOne.gif < and here
> http://www.x2x2x.org/x2x2x/images/xameleonGUITwo.gif <. I say older
as I have since switched to a browser based UI that uses client-side
XSLT 1.0-based code and javascript coupled with various ASP.NET
controls and server-side based XSLT 2.0 based code coupled with
Serverside ASP.NET components and .NET based webservices to make all
the magic happen as it ultimately seemed to be the easiest way to
ensure that you are always using the latest and greatest code base if
I build it in the browser-based client/server webservices architecture
that is made embarasingly easy (embarassing by the fact that my four
year old can now write production ready code... if things continue
going this direction pretty soon code is going to be writing us...
still, it is nice being able to build a fairly significant application
in 2 weeks when it would have taken 6 months using a classic Win32
client/server architecture a few years back)
So, those interested in following this project can add this link to
their favorites folder > http://www.xameleon.org < and check
perioducally for updates or just visit XSLTBlog.com and pick your
favorite XML feed which will be updated when I make more headway on
this project in the next few weeks... Don't panic if you go there
(xameleon.org) and see just a basic UI as thats all I had time to
develop when I first launched this project a few months back... it'll
change soon and it will be at the xameleon.org address so its all
good..
Cheers!
<M:D/>
On Wed, 29 Dec 2004 16:03:43 -0800, Jeff Rafter <lists@jeffrafter.com> wrote:
> I am working on a project which is currently in the planning stages of a
> rewrite. Already the project has some killer XML technology built-in and
> leveraging this has only provided benefits along the way. The plan for
> the product interface currently is a rich client built on WinForms in
> C#. It is my understanding that this technology will be obsoleted with
> the newer tools out of Redmond (i.e. XAML). Additionally this is not
> very extensible. So we decided to consider alternatives (i.e.,
> leveraging more XML technologies). Unfortunately the tangled morass of
> competing projects and products has left us wondering which is best (for
> our situation). This is our list, in no particular order:
>
> (A) Stick with WinForms, rewrite that part later if necessary
> (B) Use an SVG interface with SVG components
> (C) Use XForms
> (D) Use SVG and combine it with XForms
> (E) Use XUL (Mozilla/chrome)
> (F) Use XAML
>
> It is also possible that we either need to print or transport documents
> and this would likely mean that we would target one of the following for
> that piece (1) XHTML (2) SVG (3) XSL:FO. For this piece I would venture
> to guess that XSL:FO would be the "right" technology but we already have
> a lot of SVG work embedded, and painting to a printer canvas is easy
> enough. I wouldn't want to use XHTML because of the poor support for
> pagination... but I could be convinced otherwise.
>
> Some of our requirements include:
>
> (A) High speed
> (B) Data from/to an XML document in memory
> (C) User customization/ extensibility
> (D) Rich gui controls
> (E) Strong event model
>
> So are there any suggestions out there? I have used most of these
> technologies already but never for side by side comparison. Answers like
> "leave us alone, go hire a consultant" are helpful... but then I would
> ask what skill set that consultant should have :)
>
> Thanks in advance,
> Jeff Rafter
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
