I'm with Jon here: Why the heck would you want to do this?
Ok, you've defined a new XML-based scripting language to replace Java
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).
What if you wanted to use a one-way hash on the passwords? What if user
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?
For the functionality you mention, in typical MVC systems (Struts,
Maverick, WebWork, Turbine), all you need to do is define a JavaBean
something like this simplistic example (using Maverick):
class TestPassword extends ControllerBase
{
protected String pw = "";
protected String email = "";
public void setPassword(String pw) { this.pw = pw; }
public void setEmail(String email) { this.email = email; }
public String perform()
{
if (yourHelper.checkPassword(email, pw))
return "success";
else
return "error";
}
}
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
becomes very easy to encapsulate business logic in
presentation-independent facilities like EJBs or standard JavaBeans (in
this example, the yourHelper object). How would your system reuse
business logic to build a Swing client?
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?
Jeff Schnitzer
[EMAIL PROTECTED]
> -----Original Message-----
> From: Dave Jarvis [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 17, 2001 1:19 AM
> To: Jakarta General List
> Subject: Re: Business-Oriented XML
>
> Hi, Jon.
>
> > Why the heck would you want to do this anyway? You have to be nuts
to
> write
>
> To begin with, it is a very simple stepping stone for moving old
systems
> that don't scale well (e.g., FoxPro) to one that does. The system I'm
> working with has hundreds of tables, some with tens of thousands of
> rows, others with over thirty million; not hand-coding the SQL is out
of
> the question.
>
> > SQL by hand anymore and why would you want to embed it into your
code
> > anyway?
>
> Embedding the SQL in this fashion creates a tight modular unit that
> performs one piece of the entire site's functionality. For example,
> consider logging in: a relatively simple task. The user enters their
> e-mail address and password using an HTML form. To verify that they
got
> it correct, one would write:
>
> [File: /logic/Login/main.xml]
> <?xml version="1.0"?>
> <businessLogic>
> <main>
> <sql>
> <select>* FROM USERS WHERE EMAIL=? AND PASSWORD=?</select>
> <using>
> <value-of expr="$email"/>
> <value-of expr="$password"/>
> </using>
> <container name="results"/>
> </sql>
> <if test="!@results">
> <redirect expr="'http://www.yahoo.com'"/>
> </if>
> </main>
> </businessLogic>
>
> In this fashion, no other part of the system needs to know how the
login
> functionality works. Also, since the code is interpreted, you can
> change the SQL as required while the system is running.
>
> How would you write the following functionality: A web page is
> presented to the user with an HTML FORM composed of two TEXT INPUT
boxes
> (named email and password; with no hidden fields). They fill in their
> information and now the system must verify it -- simply, easily, and
> quickly. Please show me a simpler means to perform this task. Once
> that's done, please make the solution platform, language, and database
> neutral.
>
> > You guys have totally lost touch with simple concepts like 'MVC'...
>
> The Database is the Model.
> The Logic is the Controller.
> The XSL is the View.
>
> I fail to see what I'm missing. Please enlighten me!
>
> Sincerely,
> Dave Jarvis
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
