|
Replies:
28
-
Last Post:
Jun 30, 2006 12:49 PM
by: rbair
|
|
|
|
|
|
|
JDNC house cleaning
Posted:
Jun 22, 2006 12:33 PM
|
|
|
For those who've been keeping score, not a lot has happened with the JDNC project since it was split out into SwingX and Databinding. That is about to change.
The JDesktop Network Components project has been a dead area for a while since most work was going into the SwingX components and the databinding framework. Since last year, the landscape has changed and its time to bring JDNC back into action.
The current core set of projects for SwingLabs:
- SwingX
- JDIC
- TimingFramework
- DataSet (or whatever it is called: see other thread)
There are also going to be two new projects corrosponding to the two new JSRs: 295 (bean binding) and 296 (app framework).
There are also several other subprojects such as Wizard, Deployment, SwingWorker, etc that will be better incorporated into the family of projects as we go along.
So that leaves us with JDNC. What is its charter in all this?
"The JDesktop Network Components project (JDNC) will eventually house components (both visual and non-visual) for working with webservices. For example, the JXMapViewer component that was shown during the JavaOne 2006 keynote as part of the Aerith project will be released as part of the JDNC project. Basically, if the component is all about webservices or working on the net, then it'll probably end up in JDNC." -- from the faq
There are a lot of other idea's I've been kicking around, besides just the JXMapViewer. For example, I'd like to have a suite of non visual components that talk to all the major webservices:
Yahoo Geo-locator
Flickr
Delicious
weather data
financial data
event data (concerts, shows, etc)
you name it
The goal here is to gives developers a nice collection of visual and nonvisual beans they can drop on their forms to build rich internet application clients quickly.
You'll note in this charter no mention of high level components (the JN components) or declarative XML -- per se. The current JDNC codebase also includes an Application class and some helper files which is also not included in the charter. Here are my thoughts on each of these:
Application class
This really doesn't belong in JDNC, since there is an entire JSR and subproject related directly to an App framework. This should be moved to the incubator.
JN* Components
I'm still very much attached to the idea of having high level components. However, one thing at a time. For now, I want to move these to the incubator. As current projects progress and the community grows, perhaps interest in the JN* components will be such as to warrant creating a sub project devoted entirely to them.
Declarative XML
I've long been a fan of the idea of using XML as a way of declaring Swing guis (though not without my doubts!). I, like many others, started my own open source project for such a framework (shamefully, I admit starting xom.sourceforge.net. Yikes.).
As with the JN* components I don't feel the time is right for us (the for-pay Sun employees) to continue work on the JDNC markup. In particular, I'm interested in seeing how JAXX shakes out. We also just don't have the cycles to spend on this (unless somebody in the community wants to step forward!). In the meantime, I think this code should be moved to the incubator. When I am ready to endorse a particular framework, it'll be a subproject rather than part of JDNC itself.
Before any of these changes the CVS tree will be tagged.
Any thoughts on this work?
Richard
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 7:57 AM
in response to: rbair
|
|
|
It seems like giving JDNC *some* explicit focus at this point is a good idea.
One question people may have is what the value-added is. Several web
services (I know Google, for example, and Amazon) have Java APIs
already. Are you focusing on Swing data models for webservices? Or
simplfying APIs? Or visual components? I guess the Google Maps
component would be visual. Can you clarify...?
Moving the other stuff to the incubator sounds fine, would be nice if
there were a clean build process for it separate from that of
individual incubator people.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 9:43 AM
in response to: Patrick Wright
|
|
|
Hey Patrick,
> One question people may have is what the value-added
> is. Several web
> services (I know Google, for example, and Amazon)
> have Java APIs
> already. Are you focusing on Swing data models for
> webservices? Or
> simplfying APIs? Or visual components? I guess the
> Google Maps
> component would be visual. Can you clarify...?
It depends on the situation. It is true that all the major web services either provide their own Java APIs or there are readily available (of varying quality) open source libraries for accessing those web services (flickr being a prime example). With JDNC I'm not interested in reengineering any of that stuff.
However, most, if not all, of these APIs are not Java Beans. They don't usually have readily available Swing models. They don't integrate very well with the visual design process.
Usually you have to write your own data access layer that talks to the various web services (using SOAP or REST or XML-RPC, etc) and then vends data that your UI layer can access. It isn't impossible, but it raises the bar quite a bit for beginners to Swing and for smaller applications. Applications like Aerith. Applications where the data access code is an insignificant portion of the work.
What I'd like to see are simple JavaBeans that wrap the java APIs. I want to see Customizers written for these JavaBeans so that I can visually describe what data from Flickr (for example) I want to load. I want to be able to pick the Flickr bean from the component palette, drop it on my form, and then bind the properties of the Flickr bean (including results from searches, etc) to various Swing components.
I want it to be as easy to bind to web service data in the visual builder as it is to bind to database data in Delphi.
What I'm particularly interested in is enabling the low-end smashup type application. The ones that don't need to abstract the data access behind some layer because they won't ever be pulling this data from a database -- it'll always be coming from off the web.
Lowering the barrier to entry is a big part of this push.
Even for larger applications, having a nice set of JavaBean components that I can hide behind a data access layer would be nice. The conceptual model is very lightweight. Or at least, should be.
Cheers
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 10:10 AM
in response to: rbair
|
|
|
Hey Richard
I think "JavaBeans for WebServices" sounds like a great rallying cry
and an important move forward for the Java community--especially with
all the Windows Live push that Microsoft is starting to build (with
Mr. Ozzie at the helm).
IMO sounds like a good idea, and more clear to me than before.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 5:38 PM
in response to: rbair
|
|
|
I'd be very much interested in this. It would be helpful across a wide
variety of industries and really could help propel Java even more on the
desktop. I have been itching to get something going with the eBay SDK lately
and wouldn't mind starting there with something.
--Bill
On 6/22/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org>
wrote:
>
> For those who've been keeping score, not a lot has happened with the JDNC
> project since it was split out into SwingX and Databinding. That is about to
> change.
>
> The JDesktop Network Components project has been a dead area for a while
> since most work was going into the SwingX components and the databinding
> framework. Since last year, the landscape has changed and its time to bring
> JDNC back into action.
>
> The current core set of projects for SwingLabs:
> - SwingX
> - JDIC
> - TimingFramework
> - DataSet (or whatever it is called: see other thread)
>
> There are also going to be two new projects corrosponding to the two new
> JSRs: 295 (bean binding) and 296 (app framework).
>
> There are also several other subprojects such as Wizard, Deployment,
> SwingWorker, etc that will be better incorporated into the family of
> projects as we go along.
>
> So that leaves us with JDNC. What is its charter in all this?
>
> "The JDesktop Network Components project (JDNC) will eventually house
> components (both visual and non-visual) for working with webservices. For
> example, the JXMapViewer component that was shown during the JavaOne 2006
> keynote as part of the Aerith project will be released as part of the JDNC
> project. Basically, if the component is all about webservices or working on
> the net, then it'll probably end up in JDNC." -- from the faq
>
> There are a lot of other idea's I've been kicking around, besides just the
> JXMapViewer. For example, I'd like to have a suite of non visual components
> that talk to all the major webservices:
> Yahoo Geo-locator
> Flickr
> Delicious
> weather data
> financial data
> event data (concerts, shows, etc)
> you name it
>
> The goal here is to gives developers a nice collection of visual and
> nonvisual beans they can drop on their forms to build rich internet
> application clients quickly.
>
> You'll note in this charter no mention of high level components (the JN
> components) or declarative XML -- per se. The current JDNC codebase also
> includes an Application class and some helper files which is also not
> included in the charter. Here are my thoughts on each of these:
>
> Application class
>
> This really doesn't belong in JDNC, since there is an entire JSR and
> subproject related directly to an App framework. This should be moved to the
> incubator.
>
> JN* Components
>
> I'm still very much attached to the idea of having high level components.
> However, one thing at a time. For now, I want to move these to the
> incubator. As current projects progress and the community grows, perhaps
> interest in the JN* components will be such as to warrant creating a sub
> project devoted entirely to them.
>
> Declarative XML
>
> I've long been a fan of the idea of using XML as a way of declaring Swing
> guis (though not without my doubts!). I, like many others, started my own
> open source project for such a framework (shamefully, I admit starting
> xom.sourceforge.net. Yikes.).
>
> As with the JN* components I don't feel the time is right for us (the
> for-pay Sun employees) to continue work on the JDNC markup. In particular,
> I'm interested in seeing how JAXX shakes out. We also just don't have the
> cycles to spend on this (unless somebody in the community wants to step
> forward!). In the meantime, I think this code should be moved to the
> incubator. When I am ready to endorse a particular framework, it'll be a
> subproject rather than part of JDNC itself.
>
> Before any of these changes the CVS tree will be tagged.
>
> Any thoughts on this work?
>
> Richard
> [Message sent by forum member 'rbair' (rbair)]
>
> http://forums.java.net/jive/thread.jspa?messageID=126228
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
>
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 9:21 PM
in response to: rbair
|
|
|
I came to JDNC through Amy Fowler's original article on it.
http://javadesktop.org/articles/JDNC2/index.html
I guess my only input would be that the JDNC namespace sure seems cluttered by now. From your post, "The JDesktop Network Components project (JDNC) will eventually house components (both visual and non-visual) for working with webservices," sure seems like a different vision than the original scope of JDNC.
The swingx and swing-labs reorgs have helped in some aspects, but also it makes it too daunting to try and decipher all the past history to understand what we have got today vs. what was talked about yesterday. It's hard to know and track the evolution of JDNC when it's morphed so much over the last couple of years.
If you are going to start "Javabeans for WS", don't tie it to the JDNC name. It's already too crazy. Obviously, put it under the "swing labs" umbrella, but don't even mention it with the same breath as JDNC.
Maybe it's just me, but the disorganization of the JDNC/SwingLabs/SwingX project (again, just due to the evolutionary process you guys' have taken it down) hurts the overall recruiting efforts of the project. We need to get to the point of having these subprojects be household words, like Apache's stuff.
I think the issue tracker and this discussion board proves my thoughts. SwingX is almost a grown up. It should have a separate discussion board. It should have a different support structure. It shouldn't have bugs spread out across multiple bug trackers. We shouldn't even be talking about JDNC on the same list as SwingX.
I'm not flaming here. I really commend everyone for all their efforts. It's obvious that SwingLabs is going to be a real winner. It just takes time.
Adam
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 23, 2006 9:44 PM
in response to: rbair
|
|
|
Oh, I also wanted to say the vision for "JavaBeans for Web Services" is cool and all, but tieing it to existing online services (google, ebay, flickr, etc.) seems a bit gimmicky and gee-whiz.
What we _really_ need is solutions that solve problems for the majority of java developers. I'm guessing that 95%+ of all swing apps written are written as internal enterprise applications. I mean, accounting apps, inventory, bill of materials, costing, crm, erp, etc. Ebay, google, et al don't have anything to do with these types of applications.
So, the point is, for "JavaBeans for Web Services" to get real recognition from the core enterprise java development community, the moto needs to be a robust databinding type layer that can be easily configured to tie web services together with swing widgets. Now _that_ is cool.
I'm sure I am ultimately speaking to your original vision. And, having some gee-whiz example applications running against google or whatever is fine. But, I wouldn't be putting that down as my trump card or forefront marketing message or make it the project mission statement.
Aerith is great and all, but it doesn't get real developer attention like the stuff, for example, that Oracle or IBM is doing with Java.
If your new "JavaBeans for WebServices" project becomes synonymous with cool alternate ebay frontend, you will have lost.
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 24, 2006 6:25 AM
in response to: bobsledbob
|
|
|
Hi Bob
On 6/24/06, jdnc-interest@javadesktop.org <jdnc-interest@javadesktop.org> wrote:
> Oh, I also wanted to say the vision for "JavaBeans for Web Services" is cool and all, but tieing it to existing online services (google, ebay, flickr, etc.) seems a bit gimmicky and gee-whiz.
I agree, but only in part. Take a look at Google Maps. Within a few
months of release, people were creating mashups using browser
technologies alone, and creating interesting sites (I still think
housingmaps.com rocks, though I don't need to use it). The general
plumbing issues for Java on the client need to be addressed (and are
being addressed) but we also need to make it easier for people to
create useful apps using web services and Java, since all the big
companies are starting to offer interesting stuff via WS.
Also, look at the desktop mini-apps we have from Google (desktop),
Yahoo (Konqueror?), MS is realising a set with Vista--these are
natural targets for Java as well--and if written in Java, they will
need to be web-enabled to be really useful.
Whether this should be a front-line SwingLabs effort or not--that I
can't say. It does seem that we need to downplay the JN* components
and the other aspects Richard covered as they are either obsolete or
not under development. Anyway, I think that WS-enabled JavaBeans seems
like a good goal for the project.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 8:56 AM
in response to: bobsledbob
|
|
|
Hey Adam
> Oh, I also wanted to say the vision for "JavaBeans
> for Web Services" is cool and all, but tieing it to
> existing online services (google, ebay, flickr, etc.)
> seems a bit gimmicky and gee-whiz.
The focus of the SwingLabs projects haven't changed. SwingX, databinding, application framework, deployment, SwingWorker: These are all consistently working towards their goals as the underpinnings of successful Swing development whether for enterprise or "living room" grade applications.
I want the webservices project (or whatnot) to be more than just a repository of good JavaBeans encapsulating common web services. I want it to exemplify some best practices along the way. The idea is that if we don't have a prebuilt webservice for you, then it should be trivial to build your own. Don't know how? Take a look at ours!
> If your new "JavaBeans for WebServices" project
> becomes synonymous with cool alternate ebay frontend,
> you will have lost.
Don't worry, I hate the ebay API 
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 9:37 AM
in response to: rbair
|
|
|
So is it more focused toward Web Services or JavaBeans? Maybe just a JavaBeans project where developers can find best practices for beans. With the Swinglabs component store, it would be very easy to pick and choose the beans your looking for. Seems like it might revitalize the whole "beans" push again... especially with a really cool initial set of Web Services beans available.
Erik
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 10:56 AM
in response to: evickroy
|
|
|
> So is it more focused toward Web Services or
> JavaBeans? Maybe just a JavaBeans project where
> developers can find best practices for beans. With
> the Swinglabs component store, it would be very easy
> to pick and choose the beans your looking for. Seems
> like it might revitalize the whole "beans" push
> again... especially with a really cool initial set of
> Web Services beans available.
Web Service javabeans, I think. Beans in general could go in any of several subprojects, and need not be limited to just one. This one would be more oriented toward both visual and non visual network oriented beans/components. So the JXMapViewer would be one such visual component, and a YahooSearch would be one such non visual bean.
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 3:18 AM
in response to: rbair
|
|
|
Hi Richard,
goooood move to cleanup 
>
> So that leaves us with JDNC. What is its charter in all this?
Well, I tend to second Adam: not yet another morp of the subproject.
It's similar to the databinding - evolutionary drain left it without
much life Some core functionality moved (like the application -
which was moved into JDNC because it had no place anywhere else after
the splitting the old jdnc) into yet to be created projects, some never
really were alive (like the JN* ... my personal opinion on them and
some didn't get the attention they deserved (like the auto-form related
support, my pet).
What I would suggest is to let the project die gracefully: tag what's
there, delete and document as a historic milestone. Anybody wanting to
dig in old code (which is interesting even is unsupported) can always
checkout the tag.
And then create a new project dedicated to WS, with a charter as you
suggested.
> This should be moved to the incubator.
>
Well, I'm opposed to doing so (for any of the packages you mentioned) -
IMO, the incubator is for fresh ideas (at the moment they are added,
there are areas that drifted in neglect), not a place for things which
were abandoned for some reason or other. If somebody want to actively
revive the code, than that person can easily checkout the tagged version
from the old jdnc and commit to the incubator.
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 8:32 AM
in response to: Kleopatra
|
|
|
> What I would suggest is to let the project die
> gracefully: tag what's
> there, delete and document as a historic milestone.
> Anybody wanting to
> dig in old code (which is interesting even is
> unsupported) can always
> checkout the tag.
>
> And then create a new project dedicated to WS, with a
> charter as you
> suggested.
Well, if we do that, we need a name. Any ideas? How about something boring like: swing-ws. I'm sure somebody out there can come up with something more interesting
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 10:12 AM
in response to: Kleopatra
|
|
|
> Well, I'm opposed to doing so (for any of the packages you mentioned) -
> IMO, the incubator is for fresh ideas (at the moment they are added,
> there are areas that drifted in neglect), not a place for things which
> were abandoned for some reason or other. If somebody want to actively
> revive the code, than that person can easily checkout the tagged version
> from the old jdnc and commit to the incubator.
Actually, listening to Jeanette's position, I second it. The project
should only be kept alive if there is and will be active development
on them. I also agree that putting them in the incubator doesn't make
sense as that area is basically for show-and-tell; I don't know any
code in there that's actively maintained. If people want, they could
extract tagged code and start their area in the incubator and invite
others to join; and if they want, they could also revive the JDNC
project.
Anyway, I like J's position.
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 10:57 AM
in response to: Patrick Wright
|
|
|
> Anyway, I like J's position.
Sounds like a consensus is forming. Still need a name, though
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 11:27 AM
in response to: rbair
|
|
|
> Sounds like a consensus is forming. Still need a name, though
I'd suggest something like ServiceBeans. "web services" is a hip term
that might go out of style; whereas, we're talking about beans that
can interact with some "service" on the network--which could be some
type of network file server speaking a certain protocol, for example,
other than HTTP.
Some ideas:
ServiceBeans
ServaBeans
IntractaBeans
CoordaBeans
MeansBeans ("gives you the means--to do it with Beans!")
CommunicaBeans
RemotaBeans
AdaptaBeans
ExtensaBeans
PluggaBeans
TransmitaBeans
TeleBeans
FarBeans
FernBeans (for the German for "far")
and...(drum roll)...
RemoteServiceAdapters
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 27, 2006 5:48 AM
in response to: rbair
|
|
|
"WebRoaster" might be usable -- there's a couple of borderline hits on google, but nothing that looks like an overlap.
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 27, 2006 12:10 PM
in response to: rbair
|
|
|
I'm not sure if this belongs here or not, but the JCA-related links are broken on the web site. I'm assuming it's related to these changes.
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 27, 2006 6:26 PM
in response to: reden
|
|
|
Thanks for the heads up.
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 28, 2006 2:26 AM
in response to: reden
|
|
|
jdnc-interest@javadesktop.org wrote:
> I'm not sure if this belongs here or not, but the JCA-related links are broken on the web site. I'm assuming it's related to these changes.
dooohhh ... my fault: for some reason I assumed all links on the
incubator page to be magically valid during my last cleanup-round in Mar
Fixed them, now the w3c linkchecker is happy... but we still have some mess:
- there are copies of the jca (accidentally identical <g>), one in
swinglabs.org/docs/project/ and one in
swinglabs.java.dev.net/documentation/. Wiki and (now) incubator link to
the version on dev.net, the "contact us" page on swinglabs.org link to
its local version.
- the address info on the "contact us" page differs from the address
info on the jca document itself. This applies for both fax number and
email address (good old snail is the same . This might explain the
ever-ringing fax machine <g>
- contributors.html resides on swinglabs.org, but is severely outdated.
- packageOwners.html still around, but empty - obviously was never
maintained...
My suggestions:
a) keep all files at exactly one location. The location for developer
related info is java.dev.net. Incubator is targeted at developers. So
the location eeeeeeess ... jdnc-incubator.java.dev.net.
b) find out which of the two address infos is the correct one. Update
the other.
c) keep the contributors' list up-to-date: make it a rule to add the
name at the moment the access rights are granted.
d) remove the packageowners, it's redundant info anyway.
Back to fun work
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 12:24 PM
in response to: rbair
|
|
|
Sorry to beat a dead horse. I'll shutup, I promise...
I'm seeing names, but none of them is really portraying the concept very well. What is the JavaBeans for WS really trying to accomplish that's not already being handled by another project?
I guess I'm only seeing two things here:
o Web Services (usually meaning SOAP). Obviously this is not in the SwingLabs charter.
o Data Binding to above WS. Obviously, this is the data binding project (what's that data-binding JSR, I forget).
What's left? What more are you thinking? It sounds like what you're trying to define is:
JEbayTable extends JXTable; or
JFlikrImage extends JXImageView;
Again, these types of things (to me) seem more like example code than anything. Is that the point? Does example code deserve its own project? Isn't that what swinglabs-demo is supposed to be for?
All you're doing here is: swingx + data-binding + web services. If your new project is about "best of breed" or "best practices", well that's ok. It's a tutorial with example code.
If however what you're doing is making the barrier lower for JXTable injection of Web Service data, then that's interesting. A JXWebSerivceTable, JXComboWS, etc. might be pretty interesting.
Even though there's a mass of "new" and "exciting" web services being offered by the big web players, these are still one-off applications. Will JEbayTable, beyond the mere curiosity of it, really be extended upon by that many applications or developers? You might service two or three useful applications with that use it. Nobody will extend it.
Where-as JXWebServiceTable might very well service several hundred or thousands of java developers. Even then, I'm not seeing how JXWebServiceTable is all that much different than what we have today.
If the point is having a tutorial and example code, then that's fine. I get it. I guess I'd just hate to see you chasing the next "new" and "exciting" thing, promoting it like that's what java desktop is all about. Reminds me of applets.
Adam
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 1:07 PM
in response to: bobsledbob
|
|
|
> I'm seeing names, but none of them is really portraying the concept very well. What is the JavaBeans for WS really trying to accomplish that's not already being handled by another project?
Not knowing what Richard is *really* aiming at (without examples
handy), I can see a need for JavaBeans which simplify access to some
service offered remotely--currently, the interesting ones are being
offered as "web" services, such as Google Maps, Google Search, Google
Base, EBay, Amazon A9, etc.
So with Google Base, maybe I can have one bean where I specify a
search term and get a List of results, each one being one item in the
database--and conversely, can configure a bean, push data into it, and
have it update a Google Base entry. Likewise, with Google Maps, I can
configure a bean and get a grid of images returned representing the
tiles for that location, can push in an array of addresses and get the
little arrow icons put on, etc. All of this with beans that are
enabled to be used in a visual property editor.
How you actually use those is up to you. For example, you could get a
set of Maps tiles and embed them in an XHTML document that you give to
Flying Saucer, and render it as a PDF. If I can interact with Maps
using a single bean, it seems it would make life easier in interacting
with these services (and new ones are coming out regularly).
It's obvious that many big players are offering access to interesting
data sources and features using web services. Microsoft has already
declared this will be the next battleground commercially (with the
Live products). So if there is a way to enable Java developers to
quickly build on top of these services, it seems that SwingLabs will
have offered something useful.
That said--it seems it is a good idea to me.
0.02,
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 1:44 PM
in response to: Patrick Wright
|
|
|
Patrick,
Patrick Write wrote:
> I can see a need for JavaBeans which simplify access to
> some service offered remotely
Sorry, here I am again. Two thoughts...
1) What has this to do with Swing? Or SwingLabs? What you've described is totally non-visual in nature. Where's the Swing in this?
2) Creating a GoogleBaseBean, again, still strikes me as being neato and good example code. I assume though that underneath that is a more generally useful abstract class that does the actual work? So, you have FlikrBean, EbayBean, GoogleMapsBean, etc. all which extends some AbstractWebServiceBean that does the actual work?
If so, that's interesting to me because that's the kind of stuff I do all the phreaking time. That is, I use java.reflect.Proxy and interfaces to shuttle WS type requests which loads and populates (extremely simple) JavaBeans which I use as model for my guis. Having a framework for this stuff is a great idea, and/but it seems it's being done in lots of different ways.
The distinction here between AbstractWebServiceBean and the various data binding projects seems very small indeed. It seems what you're describing is nothing more than a shinier layer on a data binding project.
I guess I just "don't get" solutions looking for problems to solve. This seems like Field of Dreams... "Build GoogleBaseBean and they will come."
On a slightly different but related rant, I have yet to see a framework (in this space) which really allows complex interactions across multiple beans. For example, the various data-binding projects all seem to fall apart (or become very difficult) when complex interactions need to occur. Most (?) applications rely on interactions more complex than simple CRUD like behavior.
Most guis (at least that I've seen) have multiple gui widgets which need to interact with each other. This is where the real coding work happens. Sometimes its much easier to KISS than to try and utilize a binding framework which doesn't allow complex interactions between the bounded/managed beans.
The point is, the complexity isn't in creating GoogleBaseBean, but to combine GoogleBaseBean with FlikrBean and EbayBean.
I know I'm off topic and flaming a bit. I'm not meaning any hostility, truly. I appreciate everything you guys do.
Adam
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 2:01 PM
in response to: bobsledbob
|
|
|
Hi Adam
>From what I've always understood, one of JDNC's goals was to simplify
Swing development so the barrier to creating Swing apps was lowered,
allowing for more and better quality apps to be produced.
There are more and more quality (and interesting) services being
offered over an HTTP protocol, and having beans to interact with
these, to "drag and drop" onto your app is arguably a useful thing. I
think the idea is to have a bunch of custom beans for various services
whose properties (and property editors) allow them to be added to an
application quickly and easily. eBay is a bit of a red herring, since
it is only for auctions; but many apps would benefit from a pluggable
website search facility, word lookup, map/location lookup, online data
storage, online calculation (interest rates, currency), etc.
How much of this will be abstract I don't know, have to see what is proposed.
In my view, what we're talking about is beans that allow Java
developers to extend their apps into the realm of online services with
a minimum of effort. There will be example code, of course, but also
working beans that one can get working with right away (by looking at
the sample code).
Most of us could write extended visual Swing components, threading
utilities, data buffers, etc., and probably most of us have...the
reason to have an FOSS project is to put all the good ideas together
and build a solution that works for many of us most of the time--so,
your efforts in simplifying access to common web services will be very
welcome.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 26, 2006 2:51 PM
in response to: bobsledbob
|
|
|
> 1) What has this to do with Swing? Or SwingLabs?
> What you've described is totally non-visual in
> n nature. Where's the Swing in this?
There will be visual components as well, I suspect (such as a map component). However, even if all we were talking about were non visual components, then yes it is very important for Swing.
We're fighting for our lives, now as always. Adobe is on one side with Flex, and Microsoft is, as always, on the other side. Both of them are driving at the same space: rich internet applications. Microsoft calls them "smart clients". Adobe/Macromedia calls them "rich internet applications".
In addition, AJAX is improving. People are building tools around it and frameworks for it. In time there will be powerful GUI toolkits using AJAX. I have absolutely no doubt about that.
Internally, we usually think of Swing as the UI toolkit built on top AWT. We focus on the components and frameworks that are a part of this toolkit. However, what people really want is a complete client side solution. Hence the bean binding JSR and the app framework JSR. I see this as another piece of that puzzle. There are common web services such as mapping, traffic, weather, etc. that make good sense to bundle up and make available to people.
It is also very important that we reach out to development communities that have not in the past used Swing. I'm thinking of many web developers, Microsoft developers, Pascal (Delphi) developers, and so on. I want to enable people to write cool apps like Aerith with little difficulty.
Aerith is far from a gimicky app. It has real monetary potential. It may not be enterprise, but it is consumer. Consumer oriented apps has always been a weak spot for us. Hopefully we can take some steps to address that.
> 2) Creating a GoogleBaseBean, again, still strikes
> me as being neato and good example code. I assume
> though that underneath that is a more generally
> useful abstract class that does the actual work? So,
> you have FlikrBean, EbayBean, GoogleMapsBean, etc.
> all which extends some AbstractWebServiceBean that
> does the actual work?
The first time you need to get search results for something simple in your application (think: "define: some word" searches from Google) you'll see the value of these kinds of beans being around. I'm not interested in writing them all. I just want to write the most common mainstream ones (and a few cool ones). The hope is that a trend can be set in motion that will benefit Swing developers. Even those not using one of these simple beans.
By Web Services I most definitely DON'T mean only (or even predominantly) SOAP. I'm talking about SOAP, XML-RPC, REST, screen scraping, you name it. What I mean to enable is broad use of the internet in Swing applications, in a simple manner.
I don't think you can do that without working code. I don't think examples are enough, but they are a crucial piece. There has been working code on the net for years for sorted tables, yet everybody loves the JXTable. Why? Because it is easier to accumulate components and update them as required than it is to write and maintain them.
Another aspect that cannot be easily discounted is the "wow" effect. I'd like to see discussions on JavaLobby and theserverside about how great Swing is for writing smart clients. I'd like to see these discussions framed not in "hey, Swing is great for RIA apps", but rather the subtle messages indicating that it is generally known. Just like it is generally known that Matisse is much better than previous Java gui builders.
Cheers
Richard
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 27, 2006 7:16 PM
in response to: rbair
|
|
|
> We're fighting for our lives, now as always. Adobe is
> on one side with Flex, and Microsoft is, as always,
> on the other side. Both of them are driving at the
> same space: rich internet applications. Microsoft
> calls them "smart clients". Adobe/Macromedia calls
> them "rich internet applications".
Don't get me ranting on this topic please. Swing was positioned at the forefront last century, but is now having to play catch up due to neglect by the vendor ladened JCP. Hopefully, it isn't too late, however.
Erik
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 28, 2006 9:55 AM
in response to: rbair
|
|
|
I know it's probably a huge pain in the arse on Richard, but...
In lines with the original "house cleaning" topic (before I hijacked it), I was thinking about having the incubator be a subproject of swinglabs, as opposed to jdnc-incubator. Ie. swinglabs-incubator.
I guess my thought was for several reasons. One, the less importance of the JDNC name (vs. swinglabs). Two, the mess of the jdnc-incubator project, some code useful, some old and not so, active and inactive, etc.
Only the active code in the jdnc-incubator could be moved over and the incubator project would seem fresh again.
Eventually, I guess my thought is the JDNC project can be somewhat of a graveyard. Move the JN* components in there. Move the other somewhat outdated or unworked stuff in there. Maybe if a volunteer picks up the code and wants to do something with it (JN* for example), then it would move down to the swinglabs-incubator project.
Likewise, once a swinglabs-incubator project has died (due to lack of interest, lack of movement, etc.), it is moved into the graveyard for later reference as needed.
I just think we need an active and vibrant incubator project. This would help along those lines.
I know I'm proposing work for Richard and other Sun folk, but I'd be willing to help out as much as possible on my end. Moving files over via CVS, updating the docs, etc.
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 28, 2006 10:36 AM
in response to: bobsledbob
|
|
|
Just jumping in...
At the end of the day, it looks to me that the incubator is not as
much a graveyard as it is an infinitely extensible whiteboard that
never gets erased. There isn't activity, and there is dead code, just
because people aren't working on new ideas all that often (at least,
new ideas they want to share from the incubator).
I'd suggest that, instead of splitting into multiple incubators, we
try to improve this one, by having a more standard build process, an
easy way to archive old stuff (using a target in the build script) for
cleanup, and a super-easy way to publish new demos (of ideas) using
JNLP.
That work could be done in an afternoon; just that, all proposals to
"improve" the incubator have gone nowhere...and for my part, I didn't
want to move ahead on anything without some consensus.
Regards
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JDNC house cleaning
Posted:
Jun 30, 2006 12:49 PM
in response to: Patrick Wright
|
|
|
> I'd suggest that, instead of splitting into multiple
> incubators, we
> try to improve this one, by having a more standard
> build process, an
> easy way to archive old stuff (using a target in the
> build script) for
> cleanup, and a super-easy way to publish new demos
> (of ideas) using
> JNLP.
I kind of like that approach. I like having one big incubator with a ton of code in it -- if we can just make it more accessible then I think we'd have the problem solved.
Back to JDNC: I won't reorginize it as per the discussion on this thread. The Web Service bean project will be a new sub project. I just created it today: swingx-ws. Boring name, I know, but the others that Josh and I liked (webbeans, and a few others) were all taken. So we settled for practical .
Adam, in that project is now the BackgroundWorker -- fully doc'd and beanified. I am having trouble getting NB to recognize the BeanInfo, not sure what the issue is. I'll find out after the break. Please give it a whirl and let me know.
Richard
|
|
|
|
|
java.net RSS
