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 12:02:33 GMT
IMHO to make the concrete choice of web application framework we need
to answer the question: do we plan to develop more web-based
scripts/apps for Harmony in the future? Any suggestions?

Regards,

2006/8/3, Alexei Zakharov <alexei.zakharov@gmail.com>:
> 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

-- 
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