tutos-devel Mailing List for TUTOS

Op vrijdag 28 februari 2003 17:28, schreef Erik Enge:
> Dimitri Fontaine <dfo...@cv...> writes:
> > That goal can be reach by other ways, but as it is a matter of choice,
> > why not java... The other ways I'm thinking about include wxwindows,
> > and particulary python interface (http://wxpython.org).
>
> Have you guys looked at XUL[1]?

I just have and I think it's a big nono :-)

It is nice to build a userinterface in mozilla (basically).
It is nice that activestate thinks it can build an application (komodo) that 
way. but I want TUTOS to mature to something I can install/see/use on every 
corporate desktop in the world. (at least I think that would be cool, but I 
can be on a limb with this one :-). In my experience it is not so fast (i am 
not saying Java is blazingly fast either) but I prefer to use something that 
has been around for a longer time (call it 'proven technology') without 
immediately using punch tape for data backup.

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Dimitri Fontaine <dfo...@cv...> writes:

> That goal can be reach by other ways, but as it is a matter of choice,
> why not java... The other ways I'm thinking about include wxwindows,
> and particulary python interface (http://wxpython.org).

Have you guys looked at XUL[1]?

Erik.

Footnotes: 
[1]  <http://," rel="nofollow">http://www.xulplanet.com/>, for example.

Op vrijdag 28 februari 2003 16:28, schreef Dimitri Fontaine:
>
> That goal can be reach by other ways, but as it is a matter of choice,
> why not java... The other ways I'm thinking about include wxwindows,
> and particulary python interface (http://wxpython.org).

I believe that Jboss/j2ee etc do a lot of housekeeping already. Stuff like 
transaction management that do not have to be reinvented in Python. off 
course, I could be very wrong about this as well :-)

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Op vrijdag 28 februari 2003 16:12, schreef matthewh:
> Hello again,
>
> > so it boils down to: why java/jboss?
>
> You should read up on the features of JBoss before you make assumptions
> about its limitations. Yes, JBoss does handle jsp and web based
> connections. However it can also handle connections from a J2EE client
> application. We do not want to implement a jsp solution because of the
> limitations imposed by developing in html and javascript. The client we
> develop will be java/swing and it will talk to our server application
> which in turn talks to the database.  There is a nice tutorial about
> how to build a j2ee java client that connects to a server application
> running in JBoss (http://www.jboss.org/docs/#free-30x).
>
> We are planning to handle concurrency on the object level so the
> underlying database will not matter.
>
> I would really like to push the java solution so that the application
> can run on as many platforms as possible with the smallest amount of
> work and maintenance. I also want to push the 3-tier model because
> maintaining concurrency among clients can be difficult (depending on
> the underlying database). A server could maintain all connections from
> all clients regardless of wether the client is a web based solution or
> a locally run application.

Many thanks for your clear and concise information. 
You have convinced me :-)
What is your estimation how much work it will take to move all functionality 
to the new setup?

Since we are on the subject of Java can I ask you something else?
I know Ant is the preferred Java build system. What would in 1 or 2 lines be 
the advantage of ant compared to a Makefile?

Gero, what are your thoughts about a reimplementation of TUTOS in Java?
I know a lot of objects are there for the taking. It looks to me as though
Java could be a way for TUTOS to mature to a new level.

kind regards,


-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

On Fri, Feb 28, 2003 at 10:12:02AM -0500, matthewh wrote:

> The client we develop will be java/swing and it will talk to our
> server application which in turn talks to the database.

Great ! So it will be a desktop client, and it seems to be what we
need !

> I would really like to push the java solution so that the application 
> can run on as many platforms as possible with the smallest amount of 
> work and maintenance.

That goal can be reach by other ways, but as it is a matter of choice,
why not java... The other ways I'm thinking about include wxwindows,
and particulary python interface (http://wxpython.org).

> I also want to push the 3-tier model because maintaining concurrency
> among clients can be difficult (depending on the underlying
> database). A server could maintain all connections from all clients
> regardless of wether the client is a web based solution or a locally
> run application.

The architecture seems good to me, but as a great amount of work is
already done in PHP, what about separating the web interface (using
templates, this time) and enabling a php tutos server with xml-rpc for
any new client ?

This way we'd benefit of work already done, and we get a n-tier
application architecture !

-- 
Dimitri.
http://dim.tapoueh.org

« Non seulement Jésus-Christ était fils de dieu, Mais encore il était
d'excellente famille du coté de sa mère.»
	-- Mgr de QUÉLEN, archevèque de Paris, Sermons.

Hello again,

> so it boils down to: why java/jboss?

You should read up on the features of JBoss before you make assumptions 
about its limitations. Yes, JBoss does handle jsp and web based 
connections. However it can also handle connections from a J2EE client 
application. We do not want to implement a jsp solution because of the 
limitations imposed by developing in html and javascript. The client we 
develop will be java/swing and it will talk to our server application 
which in turn talks to the database.  There is a nice tutorial about 
how to build a j2ee java client that connects to a server application 
running in JBoss (http://www.jboss.org/docs/#free-30x).

We are planning to handle concurrency on the object level so the 
underlying database will not matter.

I would really like to push the java solution so that the application 
can run on as many platforms as possible with the smallest amount of 
work and maintenance. I also want to push the 3-tier model because 
maintaining concurrency among clients can be difficult (depending on 
the underlying database). A server could maintain all connections from 
all clients regardless of wether the client is a web based solution or 
a locally run application.

Thanks again,

Matt

On Fri, Feb 28, 2003 at 11:48:00AM +0100, Jeroen Baten wrote:
> In the other hand, java seems to be getting quiet popular these days and is 
> off-course cross platform (pls don's start a new thread on MS and Java :-).
> Since I don't know much about either from hands-on experience I don't care 
> that much as long as it proves to be a descision with a future.
> 
> so it boils down to: why java/jboss?

I've now been working in java environment for quite 2 years (building
web services, servlets, by the time of this mail a workflow system you
can interact with using xmlrpc).

I don't see any advantages on a java web client for TUTOS, and won't
promote the implementation of a JBoss solution.

If you want me to promote some new production system, I'd talk about
erlang and yaws. Not java.
       http://erlang.org
       http://yaws.hyber.org
       http://www.sics.se/~ali/results.html

And I'd still prefer a desktop GUI than another web oriented
interface. What about wxpython or ocaml/gtk, or even Qt/KDE based
solution ?
       http://www.wxpython.org/
       http://www.ocaml.org/

Regards,	   
-- 
Dimitri.
http://dim.tapoueh.org

A mouse is a device used to point at the xterm you want to type in.

Op vrijdag 28 februari 2003 11:38, schreef Dimitri Fontaine:
> For what I see, the MySQL support has lead TUTOS in not using
> constraints nor foreign keys. Some of the work made in the php sources
> should be let to the RDBM, that is ensuring you attach some entities
> to existing ones, that some field has the good format or is under some
> bounds, etc...
>
> We now are talking about making some other client, and perhaps
> implementing a data server for all those.
> At that point, my question is : Why the data server is not the RDBM ?
> Do we really need to re implement all the fonctionnality we need ?
>
> If the only reason to make all this amount of work is the support of
> MySQL, I'd prefed not supporting it.

As a design descision I would prefer to have all the logic in one place so
it is easier to fix and extend. Dividing and searching stuff between program 
and database can really mess up my day :-)

> For popularity concern, you can install PostgreSQL everywhere you
> could install MySQL (for what I know). So I don't think TUTOS
> popularity would be much impacted if we shoose stoping the mysql
> support.

It still leaves the fact that you will have to do a database export/import 
with every new PostgreSQL release.

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Op vrijdag 28 februari 2003 11:20, schreef Dimitri Fontaine:
> I agree with Jeroen on that point, and don't understand the interest
> of implementing another web-based client for TUTOS.
>
> If I understand well, the jboss solution would lead to some jsp or
> servlet development, that is web client. We already have that, I think
> we'd better work on it instead of re implementing in java.
>
> But a light weight client with an interactive GUI (you know what I
> mean) would be a great companion to the existing PHP interface.
>
> And we could also think about a pda oriented GUI, in order to be abble
> to have the calendar and some docs on the hand everywhere, everytime !
>
> I already proposed building a KDE oriented TUTOS interface to
> theKompany.com, but I don't know anything about that. I thought some
> integration of the TUTOS database with the KDE desktop, pim and
> productivity tools would be great...

I have been looking for a good excuse to dive into KDE development for some 
time, and this sounds like a good idea!

In the other hand, java seems to be getting quiet popular these days and is 
off-course cross platform (pls don's start a new thread on MS and Java :-).
Since I don't know much about either from hands-on experience I don't care 
that much as long as it proves to be a descision with a future.

so it boils down to: why java/jboss?

greetings,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

On Thu, Feb 27, 2003 at 09:31:05PM +0100, Jeroen Baten wrote:
> I have been using MySQL for some time and like it. It may not be as
> feature rich as others but it does support transactions to. I
> believe it is also the most popular Open Source database and
> dropping it could have affects on the popularity of TUTOS maybe.

For what I see, the MySQL support has lead TUTOS in not using
constraints nor foreign keys. Some of the work made in the php sources
should be let to the RDBM, that is ensuring you attach some entities
to existing ones, that some field has the good format or is under some
bounds, etc...

We now are talking about making some other client, and perhaps
implementing a data server for all those.
At that point, my question is : Why the data server is not the RDBM ?
Do we really need to re implement all the fonctionnality we need ?

If the only reason to make all this amount of work is the support of
MySQL, I'd prefed not supporting it.

For popularity concern, you can install PostgreSQL everywhere you
could install MySQL (for what I know). So I don't think TUTOS
popularity would be much impacted if we shoose stoping the mysql
support.

Regards,
-- 
Dimitri.
http://dim.tapoueh.org

Contrairement aux chasseurs qui, eux, ne sont pas des lapins, les
pollueurs, eux sont des ordures.
	-- Philippe Geluck

On Thu, Feb 27, 2003 at 09:24:57PM +0100, Jeroen Baten wrote:
> > We are not talking about a Java standalone client using JDBC talking to the
> > database directly, are we?
> 
> I for one thought we were. But I guess I am the only one. :-)

Not really...

> Since I guess I am the one who needs to be educated. Is it a really
> stupid question to ask why a java standalone client with jdbc to
> mysql is not a good idea compared to the jboss/n-tier/oracle (pun
> intended) idea?

I agree with Jeroen on that point, and don't understand the interest
of implementing another web-based client for TUTOS.

If I understand well, the jboss solution would lead to some jsp or
servlet development, that is web client. We already have that, I think
we'd better work on it instead of re implementing in java.

But a light weight client with an interactive GUI (you know what I
mean) would be a great companion to the existing PHP interface.

And we could also think about a pda oriented GUI, in order to be abble
to have the calendar and some docs on the hand everywhere, everytime !

I already proposed building a KDE oriented TUTOS interface to
theKompany.com, but I don't know anything about that. I thought some
integration of the TUTOS database with the KDE desktop, pim and
productivity tools would be great...

-- 
Dimitri.
http://dim.tapoueh.org

"Il y a deux sortes de femmes : celles qui sont jeunes et jolies, et celles
qui me trouvent bien."
	-- Sacha Guitry (1885-1957)

Op donderdag 27 februari 2003 16:38, schreef matthewh:
> Hello again,
>
> No, I am aware of the need for a J2EE Application Server. We are
> planning to use JBoss unless someone can present a better alternative.

I have heard many good things about jboss (but then again, I don't have a clue 
what it does (besides jsp container and http server in one.) :-) 

> I think I am still being obtuse. 

Unlikely. I am just stupid :-). No, let me clarrify that. I do a lot of Linux 
and Open Source consulting and am a real promotor (I refer to the books I've 
written). I am just not into Java (yet) and am not a real heavy programmer 
(allthough I can make the C, PHP, Perl etc programs I need)

> > As we are talking about data management, I'd like to talk a little
> > about RDBMs supported by TUTOS.
> > Should we continue supporting MySQL ? The needs we have concerning
> > data integrity, transactions and server side treatment will quickly
> > become an issue.

I have been using MySQL for some time and like it. It may not be as feature 
rich as others but it does support transactions to. I believe it is also the 
most popular Open Source database and dropping it could have affects on the 
popularity of TUTOS maybe.

> We are planning on using MySQL since that is the database we are most
> familiar with. Postgres has made great strides since the last time I
> looked at it and now seems to be a viable alternative. It would not be
> difficult to switch change databases.

What I don;t like about postgresql is the fact that every update involves an 
export and import of the databases in use. (call me lazy :-)

kind regards.,


-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Op donderdag 27 februari 2003 12:00, schreef Geert Pante:
>  --- Jeroen Baten <jb...@i2...> wrote: > Op woensdag 26 februari 2003
> I think you missed a part:  If you implement a middle tier in J2EE, you
> allready need a J2EE Application Server.  And then it is off course easier
> to add some JSP's to the Server and have a web client talk HTTP to it, than
> to write a Java client that communicates over RMI/IIOP to the middle tier.

agree

>
> We are not talking about a Java standalone client using JDBC talking to the
> database directly, are we?

I for one thought we were. But I guess I am the only one. :-)

Since I guess I am the one who needs to be educated. Is it a really stupid 
question to ask why a java standalone client with jdbc to mysql is not a good 
idea compared to the jboss/n-tier/oracle (pun intended) idea?

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Hello again,

> I think you missed a part:  If you implement a middle tier in J2EE, you
> already need a J2EE Application Server.  And then it is of course 
> easier to
> add some JSP's to the Server and have a web client talk HTTP to it, 
> than to
> write a Java client that communicates over RMI/IIOP to the middle tier.
>
> We are not talking about a Java standalone client using JDBC talking 
> to the
> database directly, are we?
No, I am aware of the need for a J2EE Application Server. We are 
planning to use JBoss unless someone can present a better alternative. 
Our goal is that the server will manage all requests from the swing 
client to the database. It would be nice to have a single standard 
server application that handles requests from all clients (php, jsp, 
and swing). Our server could potentially fill this position.

> Isn't this solved by using database transactions?
I think I am still being obtuse. By dependencies and tasks I am 
referring to a task network (or an activity network) which should be 
part of a project management software package. I do not believe that 
TUTOS currently supports task dependencies. The table that we are 
adding to the TUTOS database is for managing the relationship between 
two or more tasks (or jobs) that have been assigned to team members. 
The following is pulled from Software Engineering: A Practitioner's 
Approach (5th Edition):
	"Individual tasks and subtasks have interdependencies based on their 
sequence. In addition, when more than one person is involved in a 
software engineering project, it is likely that development activities 
and tasks will be performed in parallel. When this occurs, concurrent 
task must be coordinated so that they will be complete when later tasks 
require their work product(s)."

> As we are talking about data management, I'd like to talk a little
> about RDBMs supported by TUTOS.
> Should we continue supporting MySQL ? The needs we have concerning
> data integrity, transactions and server side treatment will quickly
> become an issue.
>
> Using stored procedures (and some PL/SQL or PL/PgSQL) would be a great
> advantage in a multi-client environnement !
We are planning on using MySQL since that is the database we are most 
familiar with. Postgres has made great strides since the last time I 
looked at it and now seems to be a viable alternative. It would not be 
difficult to switch change databases.

- Matt

 --- Jeroen Baten <jb...@i2...> wrote: > Op woensdag 26 februari 2003 23:57,
schreef matthewh:
> 
> > The server application would not know immediately about changes made
> > from the php client. One nice feature of j2ee is that if a jsp web
> > front end were developed it would talk to the middle tier and not
> > directly to the database. Allowing the clients to connect to the
> > database directly could cause synchronization issues as you have
> > mentioned. I believe that php has some form of java support though I
> > have not used it; a future version of the php front end may be able to
> > be updated to use our server application. As it stands, you would use
> > either the web interface or our client/server combination.
> 
> The talk about moving TUTOS to Java increases. Since I am not a Java buff,
> can 
> somebody please explain why a JSP model, with a relative harder to install 
> server, is better that a Java stand-alone client?
 
I think you missed a part:  If you implement a middle tier in J2EE, you
allready need a J2EE Application Server.  And then it is off course easier to
add some JSP's to the Server and have a web client talk HTTP to it, than to
write a Java client that communicates over RMI/IIOP to the middle tier.

We are not talking about a Java standalone client using JDBC talking to the
database directly, are we?

mvg, Geert.

 --- Dimitri Fontaine <dfo...@cv...> wrote: > On Thu, Feb 27, 2003 at
09:19:08AM +0000, Geert Pante wrote:
> 
> The problem here, as already mentionned by Gero, would be the
> controller. It has to know when any tutos client update data, using
> the controller or not.
> 
> As we are talking about data management, I'd like to talk a little
> about RDBMs supported by TUTOS.
> Should we continue supporting MySQL ? The needs we have concerning
> data integrity, transactions and server side treatment will quickly
> become an issue.
> 
> Using stored procedures (and some PL/SQL or PL/PgSQL) would be a great
> advantage in a multi-client environnement !

I see the next advantages of stored procedures: 
-> It abstracts the concrete database schema.
-> It could execute some business logic rules before inserting/updating into
the table directly.

If you force all clients to use your stored procedures to access the database,
you would implement a Controller paradigm in the database tier!

However, I prefer my Controller to be implemented in J2EE instead of in SQL.  I
have to force all clients to use my Controller, too, off course.  But I think
it is easier as I can allow communication over SOAP, CORBA, Messaging, or
simple Java RMI.

greetings, Geert

On Thu, Feb 27, 2003 at 09:19:08AM +0000, Geert Pante wrote:
> -> Traditional design techniques result in tightly-coupled systems
> where a minor change in one part of the system ripples throughout
> the system, often requiring major changes in many other parts of the
> system. OOD, on the other hand, (can) produce systems where the
> different components of the system have minimal coupling, and the
> need to make a change in one part of the system will require few, if
> any, changes in other parts of the system.

PHP offers object paradigm to, and the TUTOS version currently running
make a great use of the php oop capabitlities...
On the other hand, using interfaces masking independant implementation
parts is possible without the use of that oop.

> For J2EE, I'll refer to Sun's blueprints:

As I just never used that before, I'll don't comment on this...

> Second, let's explain the benefits of a multi-tiered Model-View-Controller
> architecture:

For what I know, you can't really use a multi-tier architecture
without MVC...

The problem here, as already mentionned by Gero, would be the
controller. It has to know when any tutos client update data, using
the controller or not.


As we are talking about data management, I'd like to talk a little
about RDBMs supported by TUTOS.
Should we continue supporting MySQL ? The needs we have concerning
data integrity, transactions and server side treatment will quickly
become an issue.

Using stored procedures (and some PL/SQL or PL/PgSQL) would be a great
advantage in a multi-client environnement !

Regards,
-- 
Dimitri.
http://dim.tapoueh.org

« L'argent est préférable à la pauvreté, ne serait-ce que pour des
  raisons financières. »
	-- Woody Allen 

Op woensdag 26 februari 2003 23:57, schreef matthewh:
> I apologize for the confusing wording. By dependencies I mean the
> ability to have Task A require that other tasks (Task B, Task C, Task
> ...) be finished before  Task A can be started. I mentioned this along
> with the TUTOS Database because I believe we have to add a table to the
> database.

Isn't this solved by using database transactions?

> The server application would not know immediately about changes made
> from the php client. One nice feature of j2ee is that if a jsp web
> front end were developed it would talk to the middle tier and not
> directly to the database. Allowing the clients to connect to the
> database directly could cause synchronization issues as you have
> mentioned. I believe that php has some form of java support though I
> have not used it; a future version of the php front end may be able to
> be updated to use our server application. As it stands, you would use
> either the web interface or our client/server combination.

The talk about moving TUTOS to Java increases. Since I am not a Java buff, can 
somebody please explain why a JSP model, with a relative harder to install 
server, is better that a Java stand-alone client?

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Hi all,

I decided to send a 'me too!' message to this list since I finally found some
time to do some advanced J2EE 1.3 development, and decided to start of with the
TUTOS schema.

First of all, let's promote Java and the J2EE platform a little bit:

Java is an Object Oriented language, which, when properly designed has a number
of advantages over traditional Top-Down design:
http://home.att.net/~baldwin.dick/Intro/Java004.htm
Summary:
-> Traditional design techniques result in tightly-coupled systems where a
minor change in one part of the system ripples throughout the system, often
requiring major changes in many other parts of the system. OOD, on the other
hand, (can) produce systems where the different components of the system have
minimal coupling, and the need to make a change in one part of the system will
require few, if any, changes in other parts of the system.

For J2EE, I'll refer to Sun's blueprints:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/introduction/introduction3.html
Summary:
-> Simplified architecture and development
-> Freedom of choice in servers, tools, and components
-> Integration with existing information systems
-> Scalability to meet demand variations
-> Flexible security model

From a developers perspective, the main benefit is that in J2EE the amount of
boilerplate code for persistence, session management, request dispatching etc.
is largely reduced to using a set of standard API's and let the container
(server) take care of it.


Second, let's explain the benefits of a multi-tiered Model-View-Controller
architecture:
http://java.sun.com/blueprints/patterns/MVC.html
Summary:
-> Seperate data access, business logic, data presentation and user interaction
into seperate modules
-> Each module can be maintained and updated independently

From a developers perspective, the main benefit is that once you know the
interface for the data access tier, you can implement Business logic
independently,  once you know the interface to the Business logic tier, you
can implement user interaction logic independently, and once you know the
interface to the user interaction tier, you can implement the data presentation
logic independently.


Now for a concrete architecture for a TUTOS-database based J2EE Enterprise
Application, I started the following scenario.

Data Access:
CMP EJB's for the data access tier, and CMR for simple relations (e.g.
company-department).  For the more complex  relations, I'd work with pseudo
RelationShip EJB Objects related with the 'real' Object using CMR (e.g.
addresslocation object related to both address and location).

Business Logic:
Initially implemented in the Entity EJB's, later to
Stateless Session Beans.

User Interaction:
1:Struts
2:Maverick Controller Servlet.
3:Swing thin client
4:PHP client using java wrapper for EJB interaction

Presentation logic:
1:JSP's with Struts tags
2:Maverick XSLT using Domify -> trivial to implement for multiple clients
3:Swing thin client
4:PHP pages

As you can see, the User interaction and Presentation logic can be split
without splitting Business Logic and Data Access tier.

I'm working on a proof of concept for the company/department/address/location
management, and hope to present that soon...

greetings, Geert.

[     ir. Geert Pante, Software Development, Fit IT nv.                 ]
------------------------------------------------------------------
[  [god@universe /]# startupUniverse.sh                                    ]
[  warn: division by zero, black hole created                               ]

Here are the answers to the questions you asked about our project:

> Like Jeroen I'm interessted in your definition of dependencies 
> (foreign keys
> ?). In TUTOS some features of your database will not be used as we 
> have to be
> compliant with a wide range of different databases.

I apologize for the confusing wording. By dependencies I mean the 
ability to have Task A require that other tasks (Task B, Task C, Task 
...) be finished before  Task A can be started. I mentioned this along 
with the TUTOS Database because I believe we have to add a table to the 
database.

> I see a problem with having a 3tier architecture and allowing 
> concurrent
> access via classic webbased TUTOS. Does the middle tier know about the
> webbased changes ?

The server application would not know immediately about changes made 
from the php client. One nice feature of j2ee is that if a jsp web 
front end were developed it would talk to the middle tier and not 
directly to the database. Allowing the clients to connect to the 
database directly could cause synchronization issues as you have 
mentioned. I believe that php has some form of java support though I 
have not used it; a future version of the php front end may be able to 
be updated to use our server application. As it stands, you would use 
either the web interface or our client/server combination.

Thanks for the feedback and I hope there will be more,

Matt

On Wednesday 26 February 2003 03:18, matthewh wrote:
> A group of my colleagues and I are in the process of developing a
> solution to overcome the limitations of using TUTOS from a web based
> environment. Utilizing java, we are building a swing client and a j2ee
> server to interact with the existing TUTOS database.

That is exactly what I've planned in the very beginning of TUTOS (but=20
postponed due to excatly zero spare time). My idea was to have ONE databa=
se=20
in the background and some variation with the clients which use this=20
database. Some things like moving tasks around on a timescale will be han=
deld=20
much better with an interactiv system then with an HTML based system.

> We plan to extend the TUTOS database to handle dependencies. Would the
> original developers please comment on this.

Like Jeroen I'm interessted in your definition of dependencies (foreign k=
eys=20
?). In TUTOS some features of your database will not be used as we have t=
o be=20
compliant with a wide range of different databases.

> We want as much feedback from the TUTOS community as possible and all
> comments are greatly appreciated.

I hope you get it. But community is quiet most times.

> The project consists of three main components: a lightweight client, a
> server application, and a database. The customer will use the thin
> client which, in turn, interacts with the server. The client and the
> server will be written in java to maintain maximum compatibility and to
> alleviate porting issues. The client will be responsible for displaying
> objects and interacting with the users input. The server application
> will receive messages from the client and then retrieve objects from
> the database to return to the user.

I see a problem with having a 3tier architecture and allowing concurrent=20
access via classic webbased TUTOS. Does the middle tier know about the=20
webbased changes ?

Gero

Op woensdag 26 februari 2003 03:18, schreef matthewh:
> Hello,
>
> A group of my colleagues and I are in the process of developing a
> solution to overcome the limitations of using TUTOS from a web based
> environment. Utilizing java, we are building a swing client and a j2ee
> server to interact with the existing TUTOS database.

Out of curiosity, can you tell me how many people are involved?

>
> We plan to extend the TUTOS database to handle dependencies. Would the
> original developers please comment on this.

I am sorry, I guess I am not a database buff. What do you mean by 'including 
dependencies'?

>
> We want as much feedback from the TUTOS community as possible and all
> comments are greatly appreciated.

In that case, here goes :-)
Allthough this will overcome the usual limitations associated with a webclient 
(sessionless) it also introduces a risk. Over time it it very likely that the 
two version will start to differ in functionality and developers will have to 
choose which version to maintain. Call it "a loving fork".

Maybe if you tell me what will be so very nice about using Java I would get 
reallu enthousiastic and start coding Java as well :-)

> The project consists of three main components: a lightweight client, a
> server application, and a database. The customer will use the thin
> client which, in turn, interacts with the server. The client and the
> server will be written in java to maintain maximum compatibility and to
> alleviate porting issues. The client will be responsible for displaying
> objects and interacting with the users input. The server application
> will receive messages from the client and then retrieve objects from
> the database to return to the user.

Why devide the logic into client and server? A thick client would be able 
using JDBC to connect to the database as well, right? So why spread the 
development proces over two components with the risk of losing synchronisity?


>
> We plan on implementing resources, tasks, dependencies, gantt chart,
> and other project management related components. The customer would
> still be able to use the TUTOS online web interface as well as the java
> client that we are developing.
>
> Thanks in advance for any comments,

Looking forward to your answers.

kind regards,

-- 
  Jeroen Baten            | EMAIL :  JB...@I2...
 ____  _  __              | web   :  www.i2rs.nl
  |  )|_)(_               | tel   :  +31 (0)30 221 00 11
 _|_/_| \__)              | fax   :  +31 (0)30 220 31 91
  Kometenlaan 26, 3721 JT, Bilthoven, the Netherlands

Hello,

A group of my colleagues and I are in the process of developing a 
solution to overcome the limitations of using TUTOS from a web based 
environment. Utilizing java, we are building a swing client and a j2ee 
server to interact with the existing TUTOS database.

We plan to extend the TUTOS database to handle dependencies. Would the 
original developers please comment on this.

We want as much feedback from the TUTOS community as possible and all 
comments are greatly appreciated.

The project consists of three main components: a lightweight client, a 
server application, and a database. The customer will use the thin 
client which, in turn, interacts with the server. The client and the 
server will be written in java to maintain maximum compatibility and to 
alleviate porting issues. The client will be responsible for displaying 
objects and interacting with the users input. The server application 
will receive messages from the client and then retrieve objects from 
the database to return to the user.

We plan on implementing resources, tasks, dependencies, gantt chart, 
and other project management related components. The customer would 
still be able to use the TUTOS online web interface as well as the java 
client that we are developing.

Thanks in advance for any comments,

Matt

How about something like this?  We find this very useful.

root@cairo# diff task_ins.php /tmp/task_ins.php 
18d17
<  include("mail.pinc");
85a85
> 
139,151d138
<  /* This code sends email to the assignee whenever a new task is created
<     Erik Enge - ee...@pr... */
< 
<  $mail = new mail();
<  $mail->setFrom($current_user);
<  $mail->setSubject("TUTOS:new task:". $current_user->getFullName(). ":". StripSlashes($HTTP_POST_VARS['name']));
<  $mail->addTo($t->worker);
<  $body = $HTTP_POST_VARS['desc']. "\n\nGoto: <". getBaseURL(). $gotourl. ">" ;
<  $mail->addBody($body,"text/plain","",$current_user->lg['content_encoding']);
<  $mail->send();
< 
<  /* send-email-on-task-create code ends here */
< 
155,157d141
< 
< 
< 

I'm having a hard time administrating teams...
I don't see anything in the docs regarding the adding and removing of
team members to a certain team. Nor do i see any sort of box or method
to add/remove team members. 

Can you please help me?