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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > >> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > >> > >> > 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: > > >> [EMAIL PROTECTED] > > >> > >> > For additional commands, e-mail: > > >> [EMAIL PROTECTED] > > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > > >> > >> -- > > >> > >> Alexei Zakharov, > > >> > >> Intel Middleware Product Division > > >> > >> > > >> > >> > > >> --------------------------------------------------------------------- > > >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > >> For additional commands, e-mail: > > >> [EMAIL PROTECTED] > > >> > >> > > >> > >> > > >> > > > > >> > > > > >> > > > >> > --------------------------------------------------------------------- > > >> > Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > > >> > > > >> > > >> > > >> -- > > >> Regards, > > >> Anton Luht, > > >> Intel Middleware Products Division > > >> > > >> --------------------------------------------------------------------- > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
