Weblogs Forum - Creating Flex Components

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Creating Flex Components

29 replies on 2 pages. Most recent reply: Sep 11, 2007 2:54 PM by Martin Vilcans

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]

Dorian Gray

Posts: 7
Nickname: dgray
Registered: May, 2007

Re: Creating Flex Components

Posted: Aug 23, 2007 11:34 AM

Yes, Flex does seem to provide that sustainable model for scalable web development. The flex ecosystem is growing, and that helps.

Having extensively used XML for data interchange/Web Services, I think the technology has reached a good level of maturity. The maturity is provided again by the ecosystem/the tooling.

Incidentally, Flex integrates quite well with Web Services also. The combination makes it quite powerful tool to have a Flex based front-end integrate with backend Java EE based Web Services.

So I'm okay with XML being used in different contexts.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 23, 2007 11:48 AM

> So I'm okay with XML being used in different contexts.

I don't think the question is whether it's OK to use XML in different contexts. The question is whether it works well in each (or any) of those contexts.

Dorian Gray

Posts: 7
Nickname: dgray
Registered: May, 2007

Re: Creating Flex Components

Posted: Aug 23, 2007 12:10 PM

> I don't think the question is whether it's OK to use XML
> in different contexts. The question is whether it works
> well in each (or any) of those contexts.

I think it works well in the contexts quoted above. Especially because it has enabled the ecosystem to develop around it. By ecosystem I mean the tools, the standards, the integration/interoperational capabilities.

We have to look at XML as the enabler, but really focus on the capabilities of high-end tools & products.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 23, 2007 2:15 PM

> I think it works well in the contexts quoted above.
> Especially because it has enabled the ecosystem to
> o develop around it. By ecosystem I mean the tools, the
> standards,

MXML is essentially a proprietary standard created by Macromedia that exists on top of XML. Other than being it's own standard and following XML standard, I don't know how that would be pertinent.

On a side note, having used a number of standards built on XML my experience is that hardly anyone actually adheres to the standards.

> the integration

There is no need integration use case for MXML that I have seen.

> /interoperational capabilities.

I'm not sure what you mean here but I think you mean the same thing that I pointed out a few posts back that the biggest advantage of XML is the tools. That's a good enough reason for your average IT department to choose XML as a configuration format but Macromedia has the resources to create a parser. There are actually a lot of good tools for creating DSLs these days so this argument is weaker than it used to be.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Creating Flex Components

Posted: Aug 24, 2007 4:25 AM

> There is no need integration use case for MXML that I have
> seen.

Never say never. It would be not so nice, potentially harder, to generate files from tools, if the format would be proprietary.

> ... the biggest advantage of XML is the tools. That's a good
> enough reason for your average IT department to choose XML
> as a configuration format but Macromedia has the resources
> to create a parser.

Of course Macromedia would be able to create a parser. But it wouldn't be able to train its user base in a proprietary format as easily.

> There are actually a lot of good
> tools for creating DSLs these days so this argument is
> weaker than it used to be.

IMO, not so. Been there, done that, won't ever do it again if I don't have to. Designing a DSL is usually no trivial task, no matter what tool support you have. More so extending it after an initial version. You usually end up with a messy language, not quite fit for your purpose, but also not quite as easy to extend as you'd like/be able/willing to accept. DSLs are a good idea only when there's clearly a very limitted context in which you want to use the DSL, and where the risk that the DSL as you design it first isn't a perfect fit is very low.

--

Strictly for configuration data, before XML there was .ini or the various formats found in /etc on Unix-likes or Linux. Then there is the windows registry. Neither seems a better solution to me.

So IMO using XML as a universal language for storing configuration is a good thing.

As for XML being strictly hierarchical: IMO it is powerful enough so you can depict structures which are not hierarchical also.

The only alternative to XML which comes to my mind is JSON. But IMO this is way less familiar to web designers, and cannot be made as verbose as XML. Besides, for more complex structures, it is IMO less verbose. And there are fewer parsers available.

On the other hand, you cannot look at XML in isolation of other related technologies, not just tools. For instance XSLT, xpath and all the other stuff related to them. XML alone would probably not be a very bright idea for anything, because you'd still be forced to process it in code you have to write, but in combination with other technologies many things become easier, not only by being supported by tools. Like for instance code generation, UI generation and the like.

Nevertheless (to return the discussion to its original topic), I don't see flex as the new killer UI technology. It's closed, it's at the whims of one single commercial entity, there's little support for it from programmers typically doing desktop apps, there's little support for it from programmer typically doing server-based development, and from a user's point of view it has a behavior similar to that of Java applets - i.e. it tends to download slowly and requires a plugin and a supporting browser. The only ppl who seem to like it are ppl doing heavy web sites, requiring a lot more work in the UI than on the backend. I don't think there's the big money, or the big pile of work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 24, 2007 6:03 AM

> > There is no need integration use case for MXML that I
> have
> > seen.
>
> Never say never. It would be not so nice, potentially
> harder, to generate files from tools, if the format would
> be proprietary.

I don't think this necessarily the case. Generating files in a given format is easy. It's parsing that's the hard part.

> Of course Macromedia would be able to create a parser. But
> it wouldn't be able to train its user base in a
> proprietary format as easily.

The format is still proprietary. Is just implemented on top of XML. I'm not convinced by arguments that using XML makes things easier to understand or learn. XML is mostly noise.

> > There are actually a lot of good
> > tools for creating DSLs these days so this argument is
> > weaker than it used to be.
>
> IMO, not so. Been there, done that, won't ever do it again
> if I don't have to. Designing a DSL is usually no trivial
> task, no matter what tool support you have. More so
> extending it after an initial version. You usually end up
> with a messy language, not quite fit for your purpose, but
> also not quite as easy to extend as you'd like/be
> able/willing to accept. DSLs are a good idea only when
> there's clearly a very limitted context in which you want
> to use the DSL, and where the risk that the DSL as you
> design it first isn't a perfect fit is very low.

What tools did you use? When was that?

> As for XML being strictly hierarchical: IMO it is powerful
> enough so you can depict structures which are not
> hierarchical also.

You can do it but XML offers no support for it. You are on your own to determine how to achieve this.

> The only alternative to XML which comes to my mind is
> JSON. But IMO this is way less familiar to web designers,
> and cannot be made as verbose as XML. Besides, for more
> complex structures, it is IMO less verbose. And there are
> fewer parsers available.
>
> On the other hand, you cannot look at XML in isolation of
> other related technologies, not just tools. For instance
> XSLT, xpath and all the other stuff related to them. XML
> alone would probably not be a very bright idea for
> anything, because you'd still be forced to process it in
> code you have to write, but in combination with other
> technologies many things become easier, not only by being
> supported by tools. Like for instance code generation, UI
> generation and the like.

I agree but I think these tools could be applied to other formats. All you needs a format that is equivalent to a subset of XML in the structures it can support and a translator.

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Creating Flex Components

Posted: Aug 24, 2007 6:43 AM

> Strictly for configuration data, before XML there was .ini
> or the various formats found in /etc on Unix-likes or
> Linux. Then there is the windows registry. Neither seems a
> better solution to me.

I'm not sure what issues there are with the *nix configuration files. Typically, they're simple to read and maintain. Perhaps there's some merit for a software company using XML as configuration files if they're going to create a DTD first and use it to cookie cutter different product lines. But, my experience writing servers for in-house use is that the simplicity of a line like "some parameter=some value" is far preferable to what I've read of XML.

> Nevertheless (to return the discussion to its original
> topic), I don't see flex as the new killer UI technology.
> It's closed, it's at the whims of one single commercial
> entity, there's little support for it from programmers
> typically doing desktop apps, there's little support for
> it from programmer typically doing server-based
> development, and from a user's point of view it has a
> behavior similar to that of Java applets - i.e. it tends
> to download slowly and requires a plugin and a supporting
> browser. The only ppl who seem to like it are ppl doing
> heavy web sites, requiring a lot more work in the UI than
> on the backend. I don't think there's the big money, or
> the big pile of work.

I could be wrong but I don't think Flex is meant for desktop development until AIR comes out. Do you have experience with the AIR? I'm curious about how well it works.

Does Flex do server-side stuff? I've only read about its UI capabilities. Could you point me to what you've read about it being full end-to-end?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 24, 2007 7:26 AM

> > Strictly for configuration data, before XML there was
> .ini
> > or the various formats found in /etc on Unix-likes or
> > Linux. Then there is the windows registry. Neither seems
> a
> > better solution to me.
>
> I'm not sure what issues there are with the *nix
> configuration files. Typically, they're simple to read and
> maintain. Perhaps there's some merit for a software
> company using XML as configuration files if they're going
> to create a DTD first and use it to cookie cutter
> different product lines. But, my experience writing
> servers for in-house use is that the simplicity of a line
> like "some parameter=some value" is far preferable to what
> I've read of XML.

One of the biggest headaches with XML is that there's no consistent approach to that kind of declaration. Some people do this:


<some-parameter>some value</some-parameter>

And others do this:


<some-parameter value="some value"/>

Neither of which is as easy to read and understand as:


some-parameter=some value

In addition, the props file approach has the advantage that anything from the '=' to the next newline can be interpreted as literal text. You don't need to escape. This makes it much easier to edit by hand. Consider the following:


<up-hill value="&amp;quot;Jack &amp;amp; Jill&amp;quot;"/>

vs.


up-hill="Jack & Jill"

And then there is the awesome commenting syntax:


<!-- this is a comment -->

as opposed to:


# this is a comment

The other thing that is problematic with XML is that it's perfectly acceptable to dump it with no indentation. Or worse, put in line breaks at arbitrary points. Unless you specifically force pretty-printing, the XML will be output onto a single line. For non-trivial XML files, this makes them essentially impossible to edit by hand without a tool to assist. Add in a bunch of extraneous namespace declarations, some CDATA sections and other queer holdovers from *ML standards from the past and you get a really big pain in the ass.

One of the biggest problems I've run into with code stored as XML is that most tools that serialize XML produce unstable output with regard to changes. For example, the XML might look like this initially:


<code>
   <method name="a"/>
   <method name="b"/>
   <method name="c"/>
</code>

And then you make a change and end up with:
<code>
<method name="b"/>
<method name="a"/>
<method name="d"/>
<method name="c"/>
</code>

This drives you standard diff tool crazy. For a trivial example it seems minor but in reality the diff basically thinks everything is changed in the file. Forget trying to merge. Just remember what you did, get the new version and re-implement. We even had a XML aware diff tool but it refused to compare two XML files as XML unless the file extension was 'xml' which of course, it was not.

Anyway, I've worked with a number of tools that use XML to store their source and configuration and its a nightmare. I really wish it would stop.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 24, 2007 7:28 AM

Sorry, it wasn't clear whether encoding was being preprocessed:

That one example should be:


<up-hill value="&quot;Jack &amp; Jill&quot;"/>

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Creating Flex Components

Posted: Aug 24, 2007 8:29 AM

> Sorry, it wasn't clear whether encoding was being
> preprocessed:
>
> That one example should be:
>


> <up-hill value=""Jack & Jill""/>
>

No offense intended, but BOY is that ugly! I can't believe it would be preferred over the simplicity of
log-file-name=
read-buffer-size=

etc...

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Creating Flex Components

Posted: Aug 26, 2007 6:21 PM

Although I have typically detested the overuse of XML for everything -- for Thinking in Java I wrote a tool that automatically creates Ant files so I wouldn't have to do it by hand -- for some reason I haven't found it terribly awful in MXML. I think it's because it's reasonably terse, whereas hand-coding most XML really shouldn't be done by humans (Elliotte Rusty Harold once told me he writes all his books using XML, which just sounds dreadful to me but he seemed to like typing all those angle braces). Of course, I've gotten used to having FlexBuilder do a fair amount of it for me, and I'm sure part of it is that I've just gotten used to it.

Personally, I'd probably like to see a more Pythonic syntax used for a lot of languages like this.

Interesting challenge for Ruby DSL experts: I wonder how difficult it would be to write a DSL that produces MXML.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Aug 27, 2007 6:35 AM

> Although I have typically detested the overuse of XML for
> everything -- for Thinking in Java I wrote a tool that
> automatically creates Ant files so I wouldn't have to do
> it by hand -- for some reason I haven't found it terribly
> awful in MXML. I think it's because it's reasonably terse,
> whereas hand-coding most XML really shouldn't be done by
> humans (Elliotte Rusty Harold once told me he writes all
> his books using XML, which just sounds dreadful to me but
> he seemed to like typing all those angle braces). Of
> course, I've gotten used to having FlexBuilder do a fair
> amount of it for me, and I'm sure part of it is that I've
> just gotten used to it.

I think O'Reilly (or some other publisher) required DocBook for all their books or something like that. DOcBook used to be in implemented SGML but was redone in XML. Actually XML is pretty good for writing books (although a good WYSIWYG editor would be a big help). It's really no different than working with your typical word processing application these days (usually Word.) I played around with DocBook for to produce some technical documentation and it's nice because you can write it and then tweak the appearance with stylesheets.

> Personally, I'd probably like to see a more Pythonic
> syntax used for a lot of languages like this.

I've been thinking of developing a Python-esque form of simplified XML but haven't seen much interest.

io nous

Posts: 2
Nickname: ionous
Registered: Jul, 2007

Re: Creating Flex Components

Posted: Sep 2, 2007 10:06 AM

> I've been thinking of developing a Python-esque form of
> simplified XML but haven't seen much interest.

for python-esque files you should look into both json (http://www.json.org/example.html) and yaml (http://www.yaml.org/start.html).

i have a high opinion of both -- yaml's syntax reads simpler; json's specification has fewer gotchas.

just as json is ultimately a very small subset of javascript, i'm sure there's probably an imperative subset of python that would make a nice data language, tho i *believe* there's already good python based json and yaml parsers ready for use.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Creating Flex Components

Posted: Sep 4, 2007 6:50 AM

> > I've been thinking of developing a Python-esque form of
> > simplified XML but haven't seen much interest.
>
> for python-esque files you should look into both json
> (http://www.json.org/example.html) and yaml
> (http://www.yaml.org/start.html).
>
> i have a high opinion of both -- yaml's syntax reads
> simpler; json's specification has fewer gotchas.
>
> just as json is ultimately a very small subset of
> javascript, i'm sure there's probably an imperative subset
> of python that would make a nice data language, tho i
> *believe* there's already good python based json and yaml
> parsers ready for use.

I've looked at those in the past. I could be wrong but I don't think they hit the niche that I am looking to fill. I would like something that could be trivially converted to XML. The reason would be that if this were the case, then it could piggyback off of the existing libraries for XML and allow users to punt to XML at will. SAX and DOM parsers (etc.) could be created to parse this format as if it were XML. Existing code bases could use it without change in a lot of cases.

This could allow an organization to support both the simplified form and the XML form in a single service with very little overhead. XML has too much momentum to be replaced at this point. The idea is to create an exit strategy.

Perhaps json and yaml could do this but I don't get that idea when I look at them. It seems that their proponents assume that being better than XML is enough to displace it. I don't think it is.

Martin Vilcans

Posts: 2
Nickname: mvilcans
Registered: Sep, 2007

Re: Creating Flex Components

Posted: Sep 11, 2007 2:54 PM

I've been on vacation, so I'm joining the discussion a bit late. To continue the off topic discussion about XML, I think that the major fault of XML is that is looks ugly. If there was a convenient way to view and edit XML, I'd be quite happy with it. See my blog post: http://www.librador.com/index.php?/archives/71-In-Defense-of-XML.html

@James Watson: I have had the same idea of a format that is simpler than XML but still compatible with it (perhaps losslessly convertable back and forth to XML). I'd like to hear more about your pythonesque simplified XML.

Flat View: This topic has 29 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic