Just a point on size, why do you use the entire b7 BeanShell package for scripting, just using the core version will strip arround 100kb ... (hint)
My .2 cents on axualize & SiwxML & Thinlet Thinlet is *really* a great XML'ish widget library, MIDP & J2ME compatible as far as i know, paired with Theodore lets you build just interfaces & dessign applications with absolute MVC isolation (just on a mere 53kb wow!. Robert wrote the largest sneaky java class i've seen but, heck! it works like a charm! & fast even on old "standard" JVM 1.1.4), but the lack of many common features right now avoids thinking on it for a "serious" application. SwixML is a Swing-only (well not really true but...) , probably the slowest widget toolkit arround, heavy, sometimes buggy and not widely supported (remember, you need the *infamous/big* Sun's Java plug-in). On Axualize... Well, you do support SWT(good move, really as fast as can be) and other GUI libraries, even support scripting with BeanShell (we use it too, Pat Niemeyer did a very good work), well that's ok, but interface-layout and interface-logic must be *really* sepparated when working on large projects with distributed developpers & designers. Remember that even VB sepparates form layout from event driven logic, otehrwise is just a reedition of xsl transforms or jsp with code and usebean: just different on syntax. Abstraction on several issues is desirable in areas like automatic field validation and common tasks as filtered value lists/combos, there are several ways to do it, but binding that code to the layout doesn't seem a good idea, i know that Russell will tell us how easy is to abstract this layer, only if we knew how to use axualize and JSR-57.... but that's the point, we don't (have to/want to) learn new tricks to write code to support events & actions & such on Thinlets and shortly on SwixML. Minimizing learning curves is a critical factor to increase development production ratio, and that's the key point nowadays, Rapid Application Developpement, a missunderstood concept that is easily forgotten and missused. Split clearly interface from events, add automatic common form validation / translation / server communications, cover with easy to use and interactive tools and, voila! Keep it simple on the outside no matter how complex is inside, and they will come..... Best wishes on your project Russell. PD: Congratulations to Wolf, just can't wait to see Franklyn running .... but Don't forget Theodore!!!!!! please! Francisco Herrador STE Altran Consulting Europe ----- Original Message ----- From: "Russell White" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, February 11, 2003 3:18 PM Subject: RE: [Forum] Join forces? > Wolf, > > See my comments inline. > > --- Wolf Paulus <[EMAIL PROTECTED]> wrote: > > Russell, > > Impressive work you have done there. Looks really good and we will have a > > lot of catch up to do, to just get close to your documentation i.e. > > Thank you, same to you. I am very impressed. Axualize documentation is still > not nearly far enough for my liking. Writing docs and tutorials is always tough > for me. > > > > > However, beyond the basic concept of using XML for UI definitions, I don't > > see a lot of similarities. > > I disaggree politlely on this point since you might be surpised how much > Axualize used to look like SWIXML a year or two ago. It maybe that I see more > similarities than you do because I have the benefit of hind site. > > > Don't get me wrong Russell, but readers of this list and many others have > > discussed this issue before: > > If they are discussing features, they likely want those feature and would use > them. Why not make them available. > > > > > SWIXML is build from the ground up to be small, fast, and easy. > > These are exactly the goals of axualize. One way to make things easy is to > create facilities in your tool which you know developers will need. Just one > axample here is that Axualize has built in support for forms and marshalling > values, allowing the dveloper to pass those values to web applications in an > easy and very compact way. > > > SWIXML is focusing completely on javax.swing. > > That's great, but in my opinion does not add value. And in my humble opinion, > SWIXML will have a hard time fully supporting Swing if SWIXML stays on it's > current course. This observation is made because swing components are meant to > be extended. Extending things introduces the potential for new public > interfaces to objects to be exposed. SWIXML does not intuitively allow access > to such interfaces intoduced by said extensions. > > > Programmers who know Swing already can immediately start writing > > descriptors. > > That is true with Axualize as well. Anyone who knows swing can easily write > axualize documents. See the section on aliases. There are aliases for all of > the Swing classes, class properties, and methods which makes things very simple > and very easy to read. Another fact here is that there are aliases for all of > the Interfaces as well. This makes implementing listeners a snap. > > > No additional XML dialect has to be learned: Class names translate into tag > > names and method names into attribute names. > > This is not correct. SWIXML is an xml dialect just as Axualize is. The > difference is only that Axualize is based on an existing standard(JSR-57) and > SWIXML is not. Axualize xml syntax used to be very much like SWIXML. The SWIXML > schema is another thing which may severely limit the usefulness of SWIXML as it > is now in any case. If someone writes widgets which extend Swing widgets and > those widets expose interfaces not accounted for in SWIXML that person cannot > call methods exposed in that new interface without some extra work. This also > brings up one very important fact. Axualize is based on schemas which closely > model APIs which means that if you use schema aware XML editors such as XMLSpy > using axualize is probably much simpler than using SWIXML. > > > SWIXML is faster since no additional layers had to be added on top of the > > Swing objects. > > What extra layers? Their are not any additional layers to Axualize. I would be > extremely surpised if SWIXML was any faster, especially since I have run both > side by side. One big asset to Axualize is that it is very very fast. Add to > this the fact that it intuitively supports threads (which can be used to make > applications even better performing) and using widgets in thread safe ways, and > Axualize is probably capable of running applications faster and more realiably > than SWIXML as it is now. > > > SWIXML is smaller. Despite the fact that the SWIXML jar file is only about > > 35Kbyte in size, almost all of the infamous Swing objects are supported. > Certainly SWIXML is smaller, but not when you consider features. Axualize > supports all of the Classes in Java, as well as any custom classes you include > in the classpath or load dynamically using the <load-classes> tag. Feature for > feature Axualize is very small indeed. The core Axualize binary (axualize.jar) > is only 97K. BeanShell add 208K. So a total binary package is 315K. While this > is a little less ten times the size of your 35K, I would argue it is at least > that many times more powerful. You may have noticed that the source > distribution is large, but that is only because I include Xerces as it is a > much faster SAX parser than Crimson which is included with J2SE. Since Axualize > uses JAXP to find the parser, there is no need to use xerces if you don't want > to. You can use any JAXP SAX parser. All of the schema files are located on the > internet, and they do not need to be distributed. > > > SWIXML does Java Swing GUI generation and that is all. The dynamic behavior > > of the user interface, defining the application's business rules, has to be > > coded in Java. > > A developer using axualize could still easily take this approach if they wnted > to. But with the ability to define such behavour dynamically, why not use it? > It is very performant indeed. > > > SWIXML is not a programming language and does not support variables, > > scripting, etc. > > True, but maybe people would like to use something which does? I am not sure if > I would classify Axualize as a language, but a good friend of mine one called > Axualize an XML version of Visual Basic for Java. I did not take that very > well, but I can see where he is coming from. > > > > > This does not mean that tools/technologies like axualize, xulux, luxor, etc, > > are better or worse. > > All these tools have their place and most Java Developers are grateful to > > have a choice. > > Absolutely. I couldn't agree more. Keep in mind I have been developing Axualize > for 2+ years. It is only now going open source. It has been used with great > success, and is proven technology. Also Axualize has the benefit of building on > existing standards (JSR-57) which should help it to establish itself. > > To see how Axualize makes developing easy for those who know Swing checkout the > tutorial section on aliases. > > By the way, your project is doing quite well especially considering the limited > time you have spent on it. It is remarkable to me how much it looks like early > iterations of Axualize. Almost scary really. > > In the end, I just wanted to let you know that I think your project is very > cool, and I wanted you to have something to see as a frame of reference. > Axualize works, is proven, and solves all the problems SWIXML does and more in > a standard reliable and scalable way. > > WR > Russ White > http://freshmeat.net/projects/axualize > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > > _______________________________________________ > Forum mailing list > [email protected] > http://mars.lunarpages.com/mailman/listinfo/forum_carlsbadcubes.com >
