harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [build-test-infra] Build Test Infrastructure
Date Thu, 03 Aug 2006 11:18:49 GMT
Hi Anton,

> Regarding Struts: putting logic in JSP looks ugly for me. Puttind
> 'out.println(<html code>' to Java code looks ugly, too. I remember

There are many ways in which you can achieve the separation of
business logic from presentation layer. Have you heard about MVC (or
Model-View-Controller) paradigm? The most simple example I can think
of is:

1. You collect all information you need inside the servlet's doPost or
doGet methods
2. You store gathered information in the java bean object.
3. You put this bean object into the session (or the request) by means
of session.setAttribute() (or request.setAttribute())
4. Forward the current request to JSP page by means of
request.getRequestDispatcher(<name of your JSP>).forward(..)
5. Retrieve the stored java bean from within your JSP code by means of
either <jsp:useBean> (see [1] for details) or direct Java scripting
and display it to the user

As a result you will have the business logic of your application
encapsulated inside the servlet and the presentation logic
encapsulated inside JSP page. However, this is a hand-made variant of
the MVC-framework. :) You can also utilize exitent MVC-frameworks like
Struts and MyFaces. But they are much more complex and you will bring
extra dependencies in.

About the attached HTMLs: is there any possibility to utilize
JUnitReport to generate report pages? It will probably look nicer in
this case.

[1] http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/JSPBeans.html

Best Regards,

2006/8/2, Anton Luht <anton.luht@gmail.com>:
> Hello,
>
> I'm all open for any suggestions and wishes - I'm not an architect but
> a humble coder :)
>
> Regarding Struts: putting logic in JSP looks ugly for me. Puttind
> 'out.println(<html code>' to Java code looks ugly, too. I remember
> from my Web app development experience that Struts worked well. Why
> not use it?
>
> I've already implemented a small prototype using Perl + cgi - please
> see the screenshots attached. I'm going to make a webapp with similar
> pages.
>
> The pages are:
> - list of uploaded results (test runs)
> - upload result form
> - list of tests for each test run
> - page with test result for a single test in run
>
> Sorting, paging, filtering, comparing, etc, to be implemented later.
>
> On 8/2/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> >
> >
> > Alexei Zakharov wrote:
> > > Anton,
> > >
> > > How many pages do you plan to have in your application? I mean that
> > > Struts is probably too heavy solution for couple of pages (if this is
> > > your case). *IMHO*
> >
> > I was thinking the same thing, but was going to keep quiet unless
> > someone else spoke up.
> >
> > However, I think the real problem is scope, not the tool (as I figure
> > one simple page done in Struts is the same amount of time as one w/
> > another technology).
> >
> > Anton, could you give us a brief outline of how you hope to proceed?
> > Right now we're desperate for the basics - somewhere to post info, and
> > somewhere to read a summary across all platforms.
> >
> > geir
> >
> > >
> > > Best Regards,
> > >
> > > 2006/8/2, Anton Luht <anton.luht@gmail.com>:
> > >> Hello,
> > >>
> > >> > > I believe that there are more installations that can execute
CGI than
> > >> > > those that can run servlets. I'm sure that for the first time
the
> > >> test
> > >> > > infrastructure will be deployed to an existing installation but
> > >> not to
> > >> > > a dedicated server - that's why I decided that CGI suites better.
> > >> >
> > >> > But we aren't going to deploy the "central service" to everywhere,
just
> > >> > to the apache infrastructure.
> > >>
> > >> I don't know Apache infrastructure too well - ok, if there's a
> > >> possibility to deploy a webapp - I'll write server-side in Java, no
> > >> problem.
> > >>
> > >> If anyone objects that the technology should be Java + servlet
> > >> container, please let community know. If nobody objects I'm going to
> > >> get down to coding. I think I'll use Struts for the app.
> > >>
> > >> > > When we have a dedicated host for builds maybe it'll be worth
to
> > >> > > rewrite test infrastructure in Java. But please do not consider
the
> > >> > > choice of technology final - I just wanted to pick something
that
> > >> fits
> > >> > > for a prototype: fast to develop and easy to deploy.
> > >> >
> > >> > I'm confused.  We'll have a host to receive this info from the
> > >> > distributed build machines.  One host will be recording the info from
> > >> > the all the other distributed build machines...
> > >> >
> > >> > geir
> > >> >
> > >> > >
> > >> > > On 8/1/06, Alexei Zakharov <alexei.zakharov@gmail.com>
wrote:
> > >> > >> Hi Anton,
> > >> > >>
> > >> > >> > I believe that most
> > >> > >> > common server-side engine is CGI (not PHP or J2EE) so
I'd like to
> > >> > >> > implement this using Perl CGI scripts.
> > >> > >>
> > >> > >> (just thinking about) there are several good Java-oriented
> > >> > >> technologies - servlets, JSP, JSF - why not to use them?
I don't
> > >> like
> > >> > >> to say that servlets are more frequent than perl, but Java
itself is
> > >> > >> not the most widely used language. We should advertise it.
:) IMHO
> > >> > >> having Java web/servlets server (not a complete J2EE) for
such
> > >> type of
> > >> > >> tasks with theoretically Harmony JRE inside will do a good
job
> > >> for our
> > >> > >> project.
> > >> > >>
> > >> > >> Regards,
> > >> > >>
> > >> > >> 2006/7/28, Anton Luht <anton.luht@gmail.com>:
> > >> > >> > Hello,
> > >> > >> >
> > >> > >> > I know why this thread is so lazy - it's because everybody
> > >> dislikes QA
> > >> > >> > & testing :)
> > >> > >> >
> > >> > >> > > OK, now let me add my $0.02 about my vision about
reporting
> > >> of test
> > >> > >> > > results. I believe it's better to do this using
HTTP rather
> > >> than mail
> > >> > >> > > because some people may not have access to SMTP
port (for
> > >> example, be
> > >> > >> > > behind proxy with Exchange as mail server - I don't
really
> > >> know if it
> > >> > >> > > provides SMTP service). HTTP is open in most  configurations
> > >> and it
> > >> > >> > > was already decided that HDK and tests will be
delivered via
> > >> HTTP.
> > >> > >> > >
> > >> > >> > > I see the reporting of the results in the following
way: after
> > >> > >> > > executing tests the script packs results and uploads
them (as
> > >> with
> > >> > >> > > browser file upload) to the server. After that
data is
> > >> processed on
> > >> > >> > > server-side - daemons can send periodical e-mails,
draw charts,
> > >> > >> > > reports, lists of top test results contributors,
etc.
> > >> > >> >
> > >> > >> > Nobody criticized this approach so I assume that it's
not too
> > >> bad. I'm
> > >> > >> > going to implement a sketch for server-side bunch of
scripts - one
> > >> > >> > that accepts uploads and puts them to a temp directory
and
> > >> maybe some
> > >> > >> > simple reports. They won't use any database. I believe
that most
> > >> > >> > common server-side engine is CGI (not PHP or J2EE) so
I'd like to
> > >> > >> > implement this using Perl CGI scripts. Since this is
a first
> > >> draft,
> > >> > >> > I'm not going to use advanced templates language like
XSLT.
> > >> Including
> > >> > >> > HTML output in script is bad idea so I'm going to use
something
> > >> like
> > >> > >> > HTML::Template [1] for pages generation and CGI::Lite
[2] for
> > >> requests
> > >> > >> > handling.
> > >> > >> >
> > >> > >> > Perl is chosen just because it suites well for fast
prototyping
> > >> > >> development.
> > >> > >> >
> > >> > >> > If nobody objects, I'm going to start coding.
> > >> > >> >
> > >> > >> > [1] http://html-template.sourceforge.net/
> > >> > >> > [2] http://search.cpan.org/~smylers/CGI-Lite-2.02/Lite.pm
> > >> > >> >
> > >> > >> > --
> > >> > >> > Regards,
> > >> > >> > Anton Luht,
> > >> > >> > Intel Middleware Products Division
> > >> > >> >
> > >> > >> >
> > >> ---------------------------------------------------------------------
> > >> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> > >> > To unsubscribe, e-mail:
> > >> harmony-dev-unsubscribe@incubator.apache.org
> > >> > >> > For additional commands, e-mail:
> > >> harmony-dev-help@incubator.apache.org
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >>
> > >> > >> --
> > >> > >> Alexei Zakharov,
> > >> > >> Intel Middleware Product Division
> > >> > >>
> > >> > >>
> > >> ---------------------------------------------------------------------
> > >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> > >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> > >> For additional commands, e-mail:
> > >> harmony-dev-help@incubator.apache.org
> > >> > >>
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Regards,
> > >> Anton Luht,
> > >> Intel Middleware Products Division
> > >>
> > >> ---------------------------------------------------------------------
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >>
> > >>
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>


-- 
Alexei Zakharov,
Intel Middleware Product Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message