jmailsrv-development

[Jmailsrv-development] Web tier architecture

[Ben C. <sky...@ro...>]

Hi all,
 From response to yesterday's post, it has become obvious that an XSLT 
model is causing too much controversy to get off the ground.  So as I 
understand it, this is the architecture that has been decided upon:

o)  the mail server web tier gets an HTTP request for the admin login 
page, which is a JSP.  

o)  The form submit uses RMI to get the actual mail server to validate 
the user, upon which either the login page is redisplayed (error msg?), 
or the administration JSP is called and displayed, by parsing the config 
XML file and presenting the data to the user.  

o)  The user then posts the data back to the JSP, which uses RMI to send 
the updated info to the mail server.  

o)  Depending on which values were updated, the JSP figures out whether 
a restart is necessary and if it is, a message is included in the 
returned HTML indicating so.

That's all I can think of for the administration piece, but I think the 
Web Mail interface shouldn't be much different (except it actually gets 
mail, marks as read etc. etc.).  Please update me as to anything I've 
missed.

So the question becomes, who does what?  From what I understand the RMI 
stuff is substantially written, and Chris is working on the web tier 
code to talk to it.  This pretty much leaves JSP's to be written as I 
see it, and Eugene and I to do it.  Chris, if you're comfortable 
continuing to write RMI code, then Eugene, let's identify how many JSP's 
we need, what each does, and who should do it (assuming nobody has yet).

One last thing, I am fine with moving on and going to a JSP model, but 
Eugene, I don't think you gave my suggestions due credit or thought, 
specifically these points:

EV>  If there will be new options, what will you do with your xslt file 
? Create new version each time ?
Yes, someone would absolutely have to make a new XSLT if the config XML 
file changed.  However, the servlet may not even need recompiling if we 
were smart about it.  Were you insinuating that with a JSP model, we 
wouldn't have to rewrite under the same circumstances?

EV>  Ok, there is nothing on this page, but usual java scriptlets. 
What's the novelty ? It is convinient only for pages with really small 
amount of code in background.
Having used XSP first-hand, I can tell you that it is not merely useful 
for small amounts of Java code, I have written XSP's that have well over 
a hundred lines of Java code in them which run beautifully.  Also, I was 
not suggesting the use of XSP, merely pointing out that JSP is quickly 
becoming a dated technology.

EV>  And finally why it is better for our project ?
It is better for our project because it allows people to port the web UI 
to just about anything, including being used as an integrated backend 
mail system in larger apps of just about any language, without writing 
or rewriting a single character of Java code, just the XSLT files used 
to present that information.   Also, it allows us to create 
administration tools that are accessible from just about any device, 
including PDA's and Cellphones.  If we are capable of putting more 
functionality into this product, why would we not? We do not know what 
everyone will use it for or what their requirements will be, we are just 
the ones trying to satisfy everyone that does use it.

EV>  It's just usual marketing phrases.
Why would an organization that does not earn a cent, that is based on 
developer contributions exactly as this JMailSrv project is [the Apache 
group, makers of coccoon, the first XSP implementation], care about 
marketing or hype?  Their main reason for existence is offering free 
implementations of standards created by people like the W3C.  They only 
exist to make our lives easier.

Have a good weekend all,

Ben.

Re: [Jmailsrv-development] Web tier architecture

[Chris D. <c.d...@cd...>]

Hi,

OK, so we are agreed then?

Right then, lets get on and write some code.  I'll write some Web
Configuration Client beans for accessing the server's configuration via RMI
as soon as I hear from Johannes whether we should continue with the old
RMI interface on the server, or use the new one that I wrote. I'll write a
couple of interfaces first so that everbody else knows exactly what the
backend will look like, so that you can get on writing the front end as
soon as possible.

Thanks,
C.Davies

Ben Clarke wrote:

> Hi all,
>  From response to yesterday's post, it has become obvious that an XSLT
> model is causing too much controversy to get off the ground.  So as I
> understand it, this is the architecture that has been decided upon:
>
> o)  the mail server web tier gets an HTTP request for the admin login
> page, which is a JSP.
>
> o)  The form submit uses RMI to get the actual mail server to validate
> the user, upon which either the login page is redisplayed (error msg?),
> or the administration JSP is called and displayed, by parsing the config
> XML file and presenting the data to the user.
>
> o)  The user then posts the data back to the JSP, which uses RMI to send
> the updated info to the mail server.
>
> o)  Depending on which values were updated, the JSP figures out whether
> a restart is necessary and if it is, a message is included in the
> returned HTML indicating so.
>
> That's all I can think of for the administration piece, but I think the
> Web Mail interface shouldn't be much different (except it actually gets
> mail, marks as read etc. etc.).  Please update me as to anything I've
> missed.
>
> So the question becomes, who does what?  From what I understand the RMI
> stuff is substantially written, and Chris is working on the web tier
> code to talk to it.  This pretty much leaves JSP's to be written as I
> see it, and Eugene and I to do it.  Chris, if you're comfortable
> continuing to write RMI code, then Eugene, let's identify how many JSP's
> we need, what each does, and who should do it (assuming nobody has yet).
>
> One last thing, I am fine with moving on and going to a JSP model, but
> Eugene, I don't think you gave my suggestions due credit or thought,
> specifically these points:
>
> EV>  If there will be new options, what will you do with your xslt file
> ? Create new version each time ?
> Yes, someone would absolutely have to make a new XSLT if the config XML
> file changed.  However, the servlet may not even need recompiling if we
> were smart about it.  Were you insinuating that with a JSP model, we
> wouldn't have to rewrite under the same circumstances?
>
> EV>  Ok, there is nothing on this page, but usual java scriptlets.
> What's the novelty ? It is convinient only for pages with really small
> amount of code in background.
> Having used XSP first-hand, I can tell you that it is not merely useful
> for small amounts of Java code, I have written XSP's that have well over
> a hundred lines of Java code in them which run beautifully.  Also, I was
> not suggesting the use of XSP, merely pointing out that JSP is quickly
> becoming a dated technology.
>
> EV>  And finally why it is better for our project ?
> It is better for our project because it allows people to port the web UI
> to just about anything, including being used as an integrated backend
> mail system in larger apps of just about any language, without writing
> or rewriting a single character of Java code, just the XSLT files used
> to present that information.   Also, it allows us to create
> administration tools that are accessible from just about any device,
> including PDA's and Cellphones.  If we are capable of putting more
> functionality into this product, why would we not? We do not know what
> everyone will use it for or what their requirements will be, we are just
> the ones trying to satisfy everyone that does use it.
>
> EV>  It's just usual marketing phrases.
> Why would an organization that does not earn a cent, that is based on
> developer contributions exactly as this JMailSrv project is [the Apache
> group, makers of coccoon, the first XSP implementation], care about
> marketing or hype?  Their main reason for existence is offering free
> implementations of standards created by people like the W3C.  They only
> exist to make our lives easier.
>
> Have a good weekend all,
>
> Ben.
>
> _______________________________________________
> Jmailsrv-development mailing list
> Jma...@li...
> https://lists.sourceforge.net/lists/listinfo/jmailsrv-development

Re: [Jmailsrv-development] Web tier architecture

[Eugene V. <gh...@ma...>]

  Hello Ben,

 Ok, if discussion is over, will someone clarify that question with passing info ?
Finally, what will we pass: xml file or object ?
BC> continuing to write RMI code, then Eugene, let's identify how many JSP's 
BC> we need, what each does, and who should do it (assuming nobody has yet).
Ok, I'll write about how I see our jsps and beans.It's just one
possible variant, may be we should think about control servlet system,
where all links points to one servlet, where all work takes place...

 login.jsp -> autorization.jsp (uses validating bean, this bean will
 perform actual check) -> forwarding (assume that user is admin) ->
 main page (ie servers.jsp).

 Now more difficult part begins, when validatebean confirms that
 login/pass is ok, it creates new bean (ie admin.class) that retrieves
 by RMI object/xml file. This file will be saved locally as temp file.
 Then when forwarding to main page takes place,
 following will happens : temp file will be parsed for sections and
 will be created main html file with links to pages, that corresponds to
 sections, that were found in file. Next, let's see on how page
 processing will go. Take for example servers.jsp.
 Servers.jsp consist of server's header and calls tag
 library method from admin.class with parameter data="servers", that
 parses temp file and looks for options from section "servers". Then
 this class generates page with servers options. Form's "action" parameter
 will always point to one file: process.jsp, where changed parameters
 will be saved to temp file by admin.class. Then when forward is going
 to servers.jsp again from process.jsp, admin.class parses again temp
 file and changed options can be seen already. The same things will be
 on each page. So when user clicks on link "Commit", temp file is sent
 back to server. When user logs out, temp file will be deleted.
  Here are some drafts for you to demonstrate, how work will be
 done:

autorization.jsp /*

<%@ page contentType="text/html; charset=windows-1251" %>
<jsp:useBean id="InitBeanId" scope="session" class="jms.InitBean" />
<jsp:setProperty name="InitBeanId" property="*" />
<% InitBeanId.validate(); %>
<% if (InitBeanId.isValid()) {%>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<jsp:setProperty name="userId" property="name" value="<%= InitBeanId.getName()%>"/>
<jsp:setProperty name="userId" property="rights" value="<%= InitBeanId.getRights()%>" />
<jsp:forward page="main.jsp" />
<% } else { %>
<jsp:setProperty name="InitBeanId" property="message" value="You entered wrong information"/>
<jsp:forward page="Init.jsp" />
<% } %>

*/

servers.jsp /*

<%@ page contentType="text/html; charset=windows-1251" %>
<%@ taglib uri="/WEB-INF/jms.tld" prefix="jmswriter" %>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<% if (userId.getName().equals("")) { %>
<jsp:forward page="Init.jsp" >
  <jsp:param name="message" value="Please log in first" />
</jsp:forward>
<% } %>
<jsp:useBean id="aw" scope="session" class="jms.AdminWriter" />
<jsp:setProperty name="aw" property="*"/>
<jsp:setProperty name="userId" property="configpage" value="servers"/>
<html>
<head>
<title>General Settings</title>
<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1'>
</head>

<body bgcolor='#CCCCCC' text='#000000'>
<table width='661' border='0' cellpadding='0' cellspacing='0' mm:layoutgroup='true' height='277'>
  <tr>
    <td width='1' height='6'></td>
    <td width='660'></td>
    <td width='1'></td>
  </tr>
  <tr>
    <td width='1' height='270'></td>
    <td valign='top' width='660' height='270'>
<jmswriter:base operation="read" data="servers" /> // HERE FULFILLMENT
WITH DATA TAKES PLACE
    </td>
    <td width='1' height='270'></td>
  </tr>
</table>
</body>
</html>

*/

process.jsp /* HERE SOME CHANGES SHOULD BE PERFORMED, THIS VERSION IS
FOR STATIC PAGES, NOT FOR DYNAMIC ONES. BUT PRINCIPLE IS THE SAME.

<%@ page contentType="text/html; charset=windows-1251" %>
<jsp:useBean id="userId" scope="session" class="jms.user" />
<% if (userId.getName().equals("")) { %>
<jsp:forward page="Init.jsp" >
  <jsp:param name="message" value="Please log in first" />
</jsp:forward>
<% } %>
<jsp:useBean id="aw" scope="session" class="jms.AdminWriter" />
<jsp:setProperty name="aw" property="*"/>         /* HERE PARAMETERS
FROM PREVIOUS PAGE ARE PASSED. */
<%
String where = "";
if (userId.getConfigpage().equals("logs")) {
    where = "logs.jsp";
}
if (userId.getConfigpage().equals("jdbcs")) {
    where = "jdbcs.jsp";
    String[] pickedq = request.getParameterValues("enablejdbc");
    if (pickedq != null && pickedq.length != 0) {
      aw.setEnablejdbc("checked");
    } else {
      aw.setEnablejdbc("");
    }
}
if (userId.getConfigpage().equals("servers")) {
    where = "servers.jsp";
    String[] picked1 = request.getParameterValues("fetcherrundaemon");
    if (picked1 != null && picked1.length != 0) {
      aw.setFetcherrundaemon("checked");
    } else {
      aw.setFetcherrundaemon("");
    }
    String[] picked2 = request.getParameterValues("senderrundaemon");
    if (picked2 != null && picked2.length != 0) {
      aw.setSenderrundaemon("checked");
    } else {
      aw.setSenderrundaemon("");
    }
    String[] picked3 = request.getParameterValues("showstatuswindow");
    if (picked3 != null && picked3.length != 0) {
      aw.setShowstatuswindow("checked");
    } else {
      aw.setShowstatuswindow("");
    }
    String[] picked4 = request.getParameterValues("bigbrother");
    if (picked4 != null && picked4.length != 0) {
      aw.setBigbrother("checked");
    } else {
      aw.setBigbrother("");
    }
}
%>

<% aw.writeit(userId.getConfigpage()); %>
<jsp:forward page="<%= where%>" />

*/

 If you think, that it is overcomplicated, reply, I'm opened for any
ideas. May be we can try to simplify pages or create them different way.
Feature of this model is that all works actually is in one file - admin.class.
 
EV>>  If there will be new options, what will you do with your xslt file 
BC> ? Create new version each time ?
BC> Yes, someone would absolutely have to make a new XSLT if the config XML 
BC> file changed.  However, the servlet may not even need recompiling if we 
BC> were smart about it.  Were you insinuating that with a JSP model, we 
BC> wouldn't have to rewrite under the same circumstances?
With JSP model, that I've wrote above we do not "populate", we generate from
scratch each time, depending on our info file so there is no need in updating
client if there are new options.




Best regards, Eugene                            mailto:gh...@ma...