Anton Luht wrote: > Hello, > > I'm all open for any suggestions and wishes - I'm not an architect but > a humble coder :) > An architect is a coder with "architect" on their business card :) > 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 >> >> > > > > ------------------------------------------------------------------------ > > --------------------------------------------------------------------- > 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