Hi, Jeff.
> I'm with Jon here: Why the heck would you want to do this?
See previous reply. In addition, languages come and go. Remember when
TurboPascal was hot? QuickBASIC? C and C++? Perl? PHP? What happens
in 5 years when another awesome language makes an appearance and
everyone forgets Java? Legacy code, I believe is the term. COBOL,
FORTRAN, Smalltalk, etc. Tying yourself to a language isn't a viable
long-term strategy. I love Java, don't get me wrong. But don't fool
yourself into thinking it's going to be around forever. ;-) (This
isn't flame bait; I'm using history and nearly 20 years development
experience as a guide.) XML, on the other hand, is a technology with
staying power and a history that extends back into the late 1960s!
Another reason is that you can write more efficiently in a new
language. I've found that BOX source is typically 5 to 30 percent
smaller than equivalent Java. It has an extremely tight focus on basic
business logic.
> for defining business logic. Why? It's trivial to define such logic in
> Java, and doing so avoids the limitations of your script (whatever they
> may be).
The only limits are those imposed by the processing engine's
implementation language. (Currently Java, but could be C, C++, Perl,
etc.)
Again, coupling yourself to Java (or any language for that matter) is
not a good thing from a long-term perspective.
> What if you wanted to use a one-way hash on the passwords? What if user
I had a similar problem already. The solution:
<var name="hashKey" expr="generateHashKey( $parameter, $parameter2,
$parameter3 )"/>
So long as "generatePasswordHash" is available to the system (neither
defined nor imposed), it'll work.
> information was stored in EJBs or LDAP? What if you wanted to use the
> standard J2EE authentication and role-based security system? Can your
> script handle this?
This can be solved in either of two ways:
1) Set up a small (internal) server that uses an XML-based protocol for
information exchange.
2) Write a wrapper function to extract the information you want (e.g.,
generateHashKey).
> You can use whatever scheme you would like to test the password, limited
> only by your ability to express the behavior in Java. Furthermore, it
<if test="!checkPassword( $password )">
<var name="Phase" expr="'badPassword'"/>
<stop/>
</if>
As before, not limited to a particular language. But you might as well
use Java, because Java rocks. :-)
> this example, the yourHelper object). How would your system reuse
> business logic to build a Swing client?
No -- but then again, that wasn't what it was designed to do. It is
meant for e-commerce/web-based solutions (plus interacting with remote
servers via XML, simple file I/O, and database laughter). Nearly all
e-commerce sites do the following:
1) Present HTML to the user.
2) Gather information from the user.
3) Do something with that information.
4) Loop to Step 1.
I'm under the impression that Cocoon is a bulldozer for such a trivial
scheme. BOX, keeping the analogy, would be a shovel: simple,
straightforward, precise, and almost intuitive. (The only truly
intuitive interface is the nipple.)
I don't think this point can be stressed enough: BOX's design goal is to
solve the aforementioned 4-step process. It is tightly integrated with
XML, XSL, SQL, and file I/O -- to the intentional exclusion of all
else. It has minimal facilities required to run native code via
embedded function calls. GUI-based applications and batch processing
are beyond its ken: they would only serve to complicate the
architecture.
BOX inherently knows about state transitions, broken down by Stages and
Phases.
> And about the last point you brought up... how is your system any more
> platform, language, or database neutral than Struts, Maverick, Turbine,
> or WebWork?
If the system is coupled with Java, you lose language independence.
When I say "language" I don't mean human languages. Just in case there
was some confusion. However, BOX is both programming language and human
language neutral.
STRUTS
------
Struts is inextricably tied to Java. Struts also couples logic and
presentation (or can):
<input type="text" name="username" value="<%= loginBean.getUsername()
%>"/>
What if I wanted to limit the user names to a selection list? (Silly
example, but the idea can cause significant ripple effects; consider
typing in a catalogue name versus choosing one from a list, for those
who like practical examples.)
Struts is big and bulky; another bulldozer.
MAVERICK
--------
Maverick is tied to Java. Also allows people to shoot themselves in the
foot with JSP. And if it's true that you can use XSL without XML, it
strikes me that you're losing a whole lot of control. (I couldn't find
much information on Maverick.)
TURBINE
-------
Turbine is coupled to Java. It's not easy to use any particular
database (e.g., an entire help section on how to integrate Oracle).
With BOX, you set the default database with a straightforward
configuration file:
JDBC_DRIVER=org.postgresql.driver.Driver
DB_URL=postgres://whatever:5432
DB_USER=username
DB_PASS=password
--
JDBC_DRIVER=com.oracle.driver.Driver
etc.
Note that this is used by the processing engine. If you want to write a
processing engine in another language (like C++), then you have to
derive a mechanism to do the database connectivity. The business logic
never needs to know. Even better, you can add a DB_NAME property and
extend the BOX language thusly:
<sql name="'POSTGRESQL'">
...
</sql>
This allows people to dynamically choose a different database during
runtime (note: completely backwards and forwards compatible; BOX is
extensible).
Turbine, like Maverick, also lets you shoot yourself in the foot with
JSP.
The control over the page layout strikes me as inflexible; or at the
very least quite complicated. With BOX, you are not limited to any
particular style or layout. For example, imagine a Help system embedded
within your main site. You want to give it a different header (and
footer). With BOX, simply alter the header included within the
presentation's XSL page:
Regular header: <xsl:include
href="file://localhost/view/common/header.xsl"/>
Help header: <xsl:include href="file://view/common/help-header.xsl"/>
WEBWORK
-------
Lastly, there's WebWork. Tied to Java. (It incorrectly claims that
XML/XSLT isn't suitable for large scale application development. BOX
can handle hundreds of tables, tens of millions of rows for several
tables, for a system that has over 9000 clients, and over a million hits
a day. If that isn't a large enough scale, please hit me with the Clue
Stick.)
WebWork also does the foot shooting thing with JSP. Server Pages (JSP,
ASP, PHP) will always scale incredibly POORLY because they couple
presentation and logic. There isn't a whole lot of information on
WebWork (example source, for example) on the SourceForge site.
RED HERRING
-----------
These projects keep touting the words "object-oriented" like some sort
of Golden Solution. If your e-commerce web site is nothing more than a
glorified state machine, why do you need the power of
object-orientation? To build a robust, extensible, and scalable
solution, use the key lessons OO teaches:
o data encapsulation
o modularity
o code re-use
As a side note, read up on the works of Alan Holub for a deep
understanding of "object-oriention". There's a related page on why
"get()" accessors are bad. The links follow:
http://www.holub.com/
http://joot.com/dave/writings/articles/encapsulation.html
Conclusion
----------
In summary, BOX is an interpreted state machine. It completely
decouples presentation from logic, to the point that coupling them is
awkward (unlike ALL the other systems mentioned). The language syntax
is trivial (anyone who knows BASIC can learn BOX; there are about 20
keywords), and extensible. Current technologies either roll you over
with complexity due to supplying everything, or constrain you in various
fashions (needs Java, needs JSP, forces presentation styles, etc.). BOX
is meant to be simple and impose as few restrictions as possible, while
giving the programmer complete control over what can happen insofar as a
web site is concerned.
More database neutral?
Moreso than Turbine. As neutral as the others, yet BOX seems easier to
configure and maintain.
More language neutral?
Definitely: it doesn't impose any Java requirements.
More platform neutral?
Probably: it doesn't require Apache, Tomcat, Java, Xalan, or Xerces.
Sincerely,
Dave Jarvis
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
