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 : > Hi Anton, > > > Regarding Struts: putting logic in JSP looks ugly for me. Puttind > > 'out.println(' 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().forward(..) > 5. Retrieve the stored java bean from within your JSP code by means of > either (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 : > > 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(' 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 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 : > > > >> 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 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 : > > > >> > >> > 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