AribaWeb

The AribaWeb Team: Who We Are

2009-06-26T11:37:00.000-07:00

There have been some questions concerning the composition of the UI Framework Team at Ariba on this discussion group recently. I wanted to address these questions, reveal a little about the team behind the curtain -- and make a request of my own. :-)

We have on our team:

Kingsley: A soft-spoken, resourceful, fine-food-loving skinny guy with an amazing UI brain and extensive UI experience. An Ariba-veteran (more years than he cares to admit) who, when he is not providing guidance and dispensing knowledge to Ariba-internal folks, spends his time on AribaWeb.

Mohan: Another soft-spoken member of our team, who won his place on the UI team by writing an internal tool which demonstrated that he had basically figured out the core of AW all by himself. A relative youngster, Mohan works on Ariba-internal UI features. All AW goodness gets open-sourced, of course.

Michael: Not-at-all soft-spoken and a definite youngster. Michael keeps us entertained with his unique brand of humor. Relatively new to Ariba, Michael works on internal-to-Ariba projects and every bug he fixes in Ariba Web, you all get.

Dave: Me. Not really softly-spoken, not really skinny and a long-time Ariba engineer. The manager of this great, tightly-knit group. I was once the Architect of the Ariba Platform. These days I don't write as much code as I used to, but I poke my nose in all the stuff going on in the UI layer (as the team can attest to) and I try to be helpful. I sometimes succeed.

In addition to this modestly-sized group of engineers, there are in excess of 100 developers on Ariba application teams who use AribaWeb day-in and day-out and frequently find and fix bugs and contribute enhancements. It would also be remiss of me to fail to mention our small but talented design team who works with us on interaction paradigms and visual look.

But here's the big news: we're expanding! Yes, we're hiring!

We have an open position in the UI for an absolutely kick-ass engineer who loves UI programming; the kind of person who gets chills when he or she encounters something like AribaWeb.

Essentially: if you're reading this, *someone like you*. Or, like someone you might know.

The position is in Sunnyvale, CA. Sorry, but we can only consider local applicants. If you are interested please respond to the job posting at: http://ariba.recruitmax.com/ENG/candidates/default.cfm?szCategory=jobprofile&szOrderID=3447&szCandidateID=0&szSearchWords=&szReturnToSearch=1

We’d love to hear from you!

Localization Made Easy!

2009-05-29T19:57:00.000-07:00

There have been numerous questions on this forum about AribaWeb's support for Localization. We're finally ready to expose AW's built-in localization capabilities, and we're even throwing in some helpful new tools to streamline the localization process.

For an overview, check out this new screencast!

We are also releasing AribaWeb 5.0RC3 with a list of bug fixes and enhancements like IE8 compatibility. Please get it and test it out!

Let's Start a Wiki!

2009-03-23T21:12:00.000-07:00

Due to popular demand, we started a wiki in our Discussion Group.

You can jump straight into here.

We look forward to seeing a lot of useful content written by the community!

New "AribaWeb by Example" Tutorials!

2009-03-02T20:37:00.000-08:00

We couldn't be happier with the reception AribaWeb has received in its first two weeks in the public eye. In the interest of accelerating the learning process for our new developers we've just released some indispensable new documentation: the AribaWeb by Example developer's guide. And, to go with it, we're releasing AribaWeb 5.0RC2.

In addition to an Overview that breaks down the role of the various modules of the AribaWeb stack, the guide contains two in depth tutorials:

These chapters take a tutorial approach to introducing key framework concepts. And along the way are links to reference documentation for key AW classes and components to enable deeper exploration.

The coming few weeks will bring complete versions of the chapters on MetaUI and MetaUI-JPA, and the GA release of AribaWeb 5.0! In the meantime, please dig in to RC2 and the new documentation and let us know what you think!

Announcing AribaWeb 5.0 (RC1)

2009-02-18T10:32:00.000-08:00

The veil of secrecy is lifted: AribaWeb is going public! The AribaWeb team is proud to announce that today we are releasing the first (and likely only) release candidate before the GA release of AribaWeb 5.0: the first major Open Source release of AribaWeb!

To mark the occasion we've launched a much improved new website (http://aribaweb.org)

Here you can learn about what makes AribaWeb the premier full-stack component-based web application framework:

Auto Ajax
Instant App
Live Edit & X-Ray
Proven Full Stack

To bring it all home we, of course, had to create a new intro screencast!

You can get the full details on what's new in this release (and get the bits themselves) here -- suffice it to say that the focus of this release is performance, polish and (developer) productivity. Enjoy!

Way, Way Less Code

2009-02-13T15:40:00.000-08:00

Could AribaWeb take 100x less code than Rails to create a basic database app??? If you've checked out our latest screencast you've likely taken note of this rather extraordinary claim (and seen that the AW app has much more functionality to boot).

Can this be true? How is it possible? And does it really matter?

Why Less Code Matters

In designing AribaWeb our goal is always to capture the developers intent as directly as possible. E.g. if you want all dates to be edited using a certain control just tell us that, once. If the password field should be kept "secure" just tell use that, once. Call it extreme DRY -- we strive to make your code a declarative statement of your requirements, rather than a (repetitive) encoding of their consequences.

Why does less code matter?

The less code you need to write, the faster you can try out ideas:
Less code == More Creative.
The less code you write, the less code you need to test, debug, and maintain.
Less code == Cheaper.
The less code you have encoding your requirements, the less you have to change when those requirements change.
Less code == More Agile

So how does AribaWeb fair?

100x Less Code than Rails?!?

Both Ruby on Rails and AribaWeb make it easy to create a basic database application based on the definition of model object classes. Rails does this by way of generated "scaffolding", AribaWeb using "Instant App". To compare AW (v5.0) and Rails (v2.2.2), we created an app with three model classes (Issue, Note, and Category), each having a couple of fields. In the case of Rails this involved running:

rails MyApp
ruby script/generate scaffold Issue ...
ruby script/generate scaffold Note ...
ruby script/generate scaffold Category ...

For AribaWeb we ran aw create_project, selected the Master Detail (Groovy) template, and then added one more domain class in the resulting project.

Here's a look at the resulting applications:

And the code?

Rails: 90 Files, 10,505 lines
AribaWeb: 4 files, 90 lines
Difference: AW project has > 100x less code

Analysis

How can this be?!?

The AribaWeb app contains three compact groovy files to declare the three domain classes, a short build.xml file, and an (empty) .oss rules files. The build file inherits all of its behavior from a parent build file in the AW distribution, and both the database schema and the application UI are derived on the fly at runtime from the domain class meta data.

In the case of Rails, it's 100x disadvantage come from three sources:

Placeholder files
Rails contains (virtually empty) template files (e.g. mime_types.rb) to prompt developers where to perform specific extensions of configuration
Web Server Resources
Rail duplicates all of the frameworks required client-side resources (e.g. prototype.js) into every app project
Per-Domain Class Scaffolding
Each class gets a slew of generated layouts, a controller, a helpers, a fixture, and a db migration.

The value of placeholder files (#1) is debatable (they provide nice prompting, but can become stale as the framework evolves), but these don't contribute significantly to the total spew. #2 and #3 are the real killers.

Having every project keep copies of the Rails web resources may seem harmless (as a developer you don't have to edit these files) but the violation of module encapsulation that it entails leads to maintenance costs down the road: As new versions of the framework are released (likely with dependencies on new or modified resources) app authors are required to manage merges upon every upgrade. The biggest issue, though, is category #3...

Per-Domain Class Code Size

To get a handle on the incremental overhead for each new domain class, we added another domain class to each project. Here was the incremental code change:

Rails: 11 Files, 256 lines
AribaWeb: 1 file, 17 lines
Difference: AW project added > 15x less code

So while AW simply added a single file for the domain class and got an updated UI for free, the Rails project saw the addition of all of these:

./app/controllers/posts_controller.rb
./app/helpers/posts_helper.rb
./app/models/post.rb
./app/views/layouts/posts.html.erb
./app/views/posts/edit.html.erb
./app/views/posts/index.html.erb
./app/views/posts/new.html.erb
./app/views/posts/show.html.erb
./db/migrate/20090115233219_create_posts.rb
./test/fixtures/posts.yml
./test/functional/posts_controller_test.rb
./test/unit/post_test.rb

"But I didn't have to write this code. Does it really matter how much of it gets generated for me?"

Absolutely. Embedded in each of those files are the consequences of a set of assumptions about the kind of user interface you want for your application. Want to change the relative order of two fields? Edit all of those .erb files for that class. Want to change the component used to edit text? Edit every .erb file in your entire application.

AribaWeb is fundamentally different:

Want to change the order of two fields (in all forms)? Put this in your .oss file:

class=Post { password => email }

Want to make that change just on the creation form?

class=Post operation=create { password => email }

Want to change the control used to edit text everywhere in the application?

field type=String editing { component:MyTextEditor; }

And better still, with Live Edit you can actually make these changes on your running app, by dragging and dropping right on your running application UI.

AutoAJAX: 10x less code than GWT/JSF

AribaWeb's conciseness advantage isn't limited to model-driven database UIs.
Take for instance the case of a simple AJAX UI where a user-entered search triggers the placement of a marker on an embedded Google Map.

The authors of the ZK framework compare building this app in several different frameworks in these articles: ZK vs. GWT, ZK vs. Ajax JSF Components

A version of this mini-app built in AribaWeb is included in the Demo app in the AW distribution and can be found here.

Here's how AW stacks up:

JSF / ICEfaces: 3 files, 223 lines of code
Google Web Toolkit (GWT): 5 files, 190 lines of code
ZK: 1 file, 36 lines of code
AribaWeb: 1 file, 17 lines of code
AW Advantage: AW Project has 10x less code than GWT/JSF, 2x less than ZK

Analysis

How does AW do it? The fundamental answer is declarative binding: where the ZK code needs to explicitly script pulling data from the text field and pushing values to the Google Maps component, AW handles this automatically through bindings on the respective components.

And speaking of components, its instructive to look at what it took to build the generic Gmap components behind used in these two examples. (The source for the AW version can be found here, the ZK source here.)

ZK: 55 files, 8537 lines
AribaWeb: 6 files, 442 lines
AW Advantage: ~20x less code:

The AribaWeb commitment to simplicity is more than skin deep: reusable components (the kind that application developers author all the time as part of building their apps) use the same Auto AJAX support, and same simple declarative binding model as other application pages.

Coming Soon: Release Candidate 1

2009-02-12T16:09:00.000-08:00

Rumor has it that version 5.0 RC1 is just days away, with GA just around the corner. This is an exciting milestone for the Open Source AribaWeb project!

Version 5.0b7 Released! (12/2008)

2009-02-12T14:55:00.000-08:00

With just an hour or so left in 2008 it's time for a major AribaWeb update: AribaWeb-5.0b7.

As always there's a new screencast to show off some of what's new.

http://www.vimeo.com/2685671

In this case we build a real app (an email-integrated bug tracker with full text search, user auth, etc, etc), and show that a basic AW project has 100x less code that its Rails equivalent (and does a lot more).

See below for the full list of new features, and check out our site at http://aribaweb.org to pull the latest code.

I look forward to hearing what you think!

Start 2009 off right: Spend the 1st catching up on your AW Screencasts! :-)

- craig

AtIssue: a new full-featured demo app
- email integrated lightweight bug/task tracker
Full Text Search support via Compass/Lucene (JPA / Hibernate integration)
- automatically used in choosers and search panels
New AppCore framework:
- Basic User, Group, Permission support
- Login (local auth)
- MailMonitor
New CSV Data Loader
- Automatically initializes new schemas by loading integration/pkg.ClassName.csv files
- Support relationship initialization (automatic foreign key lookup)
New project template for Master Detail apps
- Creates app set up for AppCore, Compass, ...
New mail parsing / viewing support (AWMimeParsedMessage, MimeMessageViewer)
- Mail Client example updated to use it
MetaUI: many enhancements
- New compact field ordering (and trait application) syntax: e.g.
  zLeft => firstName => lastName; zRight => email#required => phone;
- New wrapper style traits (bold, italic, heading, ...)
- OulineBox layout
- DataTable detail row rendering support
- Generic support in MetaIncludeComponent for wrappers, named contents
  - Also, easily propagate full bag of bindings to subcomponents (awbindingDictionary binding support)
- Merge of "traits" and "trait" property (only "trait" lives on)
- Support for using parent context traits in rules affecting nested keys. e.g.:
  module-trait=CoolMode { field { editing: false } }
Bug Fixes:
- Build fix: re-builds were creating nested build directories (and breaking app re-launch)
- Some metaui Context exceptions (on nested value override chaining)
- MetaUI rapid-turnaround (reloading) fixes
- Rebuild of groovy app not rebuilding groovy classes
Updated Dependencies
- Updated to Hibernate 3.3.1, JavaMail 1.4.1, log4j-1.2.15