Re: what do you suggest me? iBatis or Hibernate
Oops, sorry third one is usually not happend, so could be out of selection. What about first tow? I did couple of enterprise application, which consists of Web front end, and many backend programs in both PL/SQL and java. The same SQLs must be appplied for different events from both front end and backend. I'm really comfortable with sharing same SQL statement in SQLMap and PL/SQL. and I just don't know how I can do this with Hibernate? Tak Diego Espada wrote in <[EMAIL PROTECTED]> >I disagree with you in some of those points. > >If you don't know SQL, don't go with Hibernate. >You'll have terrible performance problems if you do so. Hibernate has >very complete features to tweak performance and optimize queries, and >to make use of that you have to know SQL. > >I don't know iBATIS, so i don't know what advantages has over >Hibernate. But i can tell you that I've used Hibernate in an >enterprise application that was running previously on a commercial >J2EE application server with CMS with 80 users constantly beating the >Database, and the performance gains where impressive. > >For the other part, if you don't know SQL, I wouldn't recommend that >you use the domain model pattern... It would be too dangerous. I would >use transactions scripts with JDBC, let a DBA design the database and >that's it. > >Bye !!! > > >On Fri, 18 Mar 2005 21:54:28 -0500, Tak Yoshida ><[EMAIL PROTECTED]> wrote: >> I think, >> >> If you don't have to work with DBA to tune up your application's SQL >> or >> if you don't have to work with or share SQLs to any backend PL/SQL programmer >> or >> you don't know SQL very much >> The answer could be Hibernate. >> >> If yes, as usual enterprise applications, iBATIS could be the answer. >> >> Tak >> >> Milson Cardona wrote in <[EMAIL PROTECTED]> >> >Hi >> > >> >I am novice in J2EE. >> > >> >I have been working with JDBC (SQL statements within of business >> >class), but now desire to work with persitence objects. >> > >> >I know that this are different, Hibernate is then biggest, but iBatis >> >have a knowledge curve very short >> > >> >what do you suggest me? iBatis or Hibernate. >> > >> >thanks >> > >> >- >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> >> -- >> Tak Yoshida mailto:[EMAIL PROTECTED] >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: what do you suggest me? iBatis or Hibernate
I think, If you don't have to work with DBA to tune up your application's SQL or if you don't have to work with or share SQLs to any backend PL/SQL programmer or you don't know SQL very much The answer could be Hibernate. If yes, as usual enterprise applications, iBATIS could be the answer. Tak Milson Cardona wrote in <[EMAIL PROTECTED]> >Hi > >I am novice in J2EE. > >I have been working with JDBC (SQL statements within of business >class), but now desire to work with persitence objects. > >I know that this are different, Hibernate is then biggest, but iBatis >have a knowledge curve very short > >what do you suggest me? iBatis or Hibernate. > >thanks > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why complicate? was: Eliminate Setup Actions
Rick, I really appreciated that you have looked at my small idea. Please write or see the sample code. You must get something from it, if you like page oriented. OzStruts is totally different from other page oriented framework, because it runs on current Struts, meaning it's simple. I'm personally not a big fan for event driven approach with page level refresh mechanism. If I want it, I would see Echo, Flex, Lazslo, or something that is totally event driven. Frank, I have to say somethig about OzStruts, beacuse you might mis-understand it. This is totally Struts, and no additional config at all, just a standard struts-config.xml only, and even no new element like you suggested. Rick also worried about the leaning effort, but in this sense, OzStruts is more natuaral approach for Struts developer. and I believe it's less effort than leaning tiles. You can just consolidate Actions and Forms into one Page class for each jsp file, that it! Rick, your analysis could be true, 90% is cleanly done by standard Struts. but we have to know that 10% of requirements not cover thestandard Struts could cause 90% of maintenance cost, too. Tak Frank W. Zammetti wrote in <[EMAIL PROTECTED]> >Glad your on board :) I am going to work on it tonight, with a little >luck I can get at least a first iteration done and post in Bugzilla >tomorrow. Then we'll see if it passes muster for real :) > >I know what you mean about keeping up with posts... I feel like I'm >constantly missing things :) > >-- >Frank W. Zammetti >Founder and Chief Software Architect >Omnytex Technologies >http://www.omnytex.com > >Rick Reumann wrote: >> Frank W. Zammetti wrote the following on 3/7/2005 4:07 PM: >> >>> No argument here! Hence the reason I didn't want to add a new config >>> file >>> at all... my solution centers on the idea of adding one new element to an >>> Action mapping, (although, as I wrote that just now, I >>> think >>> maybe makes more sense... perhaps even making these >>> attributes of a makes more sense... eh, thinking out loud >>> now!). >>> I doubt very many people would find this onerous. >> >> >> This would be nice! If it were right in the same struts config file, I'd >> vote for this approach for sure. Nice suggestion. Sorry I missed your >> presentation of this. I can't keep up with all the posts on this list >> any more:) >> > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Ben, I don't want to bother raw Struts user's mailing list, but I would like to introduce OzStruts again. because all the Struts developers are struggling with this same issue again, again and again. I think this functionality must be prepared as part of web applicaiton framework. If you have options to use other frameworks with this function, it might be better than raw Struts. But if you need or want to use Struts, please take a look at OzStruts, which is small framework on top of Struts for page driven development. This mechanism has already been built into OzStruts as prepareRequiredProperty() method. Also you can use preListener() and postListener() to do some generic task too, such as page level security, etc. OzStruts is very simple framework, you can use your Struts knowledge as it is. I hope this would help you. Tak > >Can anyone tell me if there is an easy way to put information >(required to populate drop down boxes using data from a db) in to the >request, without having to write a setup Action for each page as is >done here: http://www.reumann.net/struts/lesson2/step9.do . > > >Thank you for any help! -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-populating a form from a database
Carlos Cajina wrote in <[EMAIL PROTECTED]> >One of the solutions I've implemented is to create an intermediate action >that loads data from a database, populates de ActionForm, and directs the >user to the apropiate JSP. This could be a better option, which has the consistent prepare method invocation. Also you can completely separate the logic to proces request, and the logic to prepare. No intermidiate action mapping is necessary. for pre-population even for validatin failure. http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334 Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Populating drop-downs
I'm not sure what you exactly want to do,
with adding value to HashTable as set method,
and creating List from the HashTable as get method.
Anyway, if you want to acces that Form you created via poppulate method,
I guess you just write Struts tag with name attribute as the name you set in
sesison,
even though codes gets strange.
I'm not sure why you don't use form object passed in Action class.
And speaking of pre-population of dropdown list,
Struts leaves the question "where we should implement?" to the application.
we need to think how to separate "process request" and "prepare for rendering".
and pre-population should be done in "prepare" cycle, and we want clear codes.
You'll see one of the solutions from
http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334
Tak
Santosh Kumar Panda wrote in <[EMAIL PROTECTED]>
>Hi,
>
>
>
>I have been facing problems populating drop-downs using dummy stub
>classes .I have used a function to populate the page containing the
>drop-down and thrown the Action Form type object into the session.
>
>
>
>Now how do I retrieve the values on to my jsp screen. Here is the code
>snippet..
>
>
>
>Action Class:
>
>..
>
>
>
>form = populate(request, iFlag);
>
>session.setAttribute("com.itest.web.form.SelectionForm", form);
>
>
>
>..
>
>
>
>...
>
>public ActionForm populate(HttpServletRequest request)
>
> {
>
>
>
> SelectionForm form = new SelectionForm();
>
> ArrayList arlproject = ProjectData.getProjects();
>
> ListIterator iter = arlproject.listIterator();
>
> while (iter.hasNext())
>
> {
>
>Project proj = (Project) iter.next();
>
>
>
>System.out.println("" +
>(String)proj.getProjectcode());
>
>form.setProjects((String)proj.getProjectcode());
>
> }
>
> return form;
>
>}
>
>
>
>SelectionForm.java
>
>
>
>public void setProjects(String strProject) {
>
>
>
>System.out.println("rr");
>
>String strKey="proj"+index;
>
>System.out.println("rr"+strKey);
>
>if (this.htbSelect.containsKey(strKey))
>
>{
>
>index++;
>
>strKey="proj"+index;
>
>}
>
> //this.htbSelect.remove("proj");
>
>this.htbSelect.put(strKey,strProject);
>
>System.out.println("rr"+index);
>
>System.out.println("ii"+htbSelect.get(strKey));
>
>
>
> }
>
>
>
> public ArrayList getProjects() {
>
> ArrayList arlProject=new ArrayList();
>
>
>System.out.println("111"+index);
>
> for(int i=0;i
> {
>
> String strKey="proj"+i;
>
> String proj=(String)this.htbSelect.get(strKey);
>
> arlProject.add(proj);
>
> }
>
>return(arlProject);
>
>}
>
>
>
>
>
> _
>
>Regrads
>
>
>
>Santosh Kumar Panda
>
>Software Engineer
>
>HTDM(extn.2680)
>
>
>
>
>
>
--
Tak Yoshida mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
OzStruts document is updated
Hi, Thanks you so much for many constructive feedbacks to OzStruts. I was surprised what a lot of people in a glow of enthusiusm are looking for better paradigm. I'm happy with these constructive discussion have started from my thread, even though most of people don't care about my stuff at all. I'm really positive. Before I will catch up new things, I want to make my baby more solid, and I still believe it's nice on current Struts. I have updated the intro doc with your feedbacks, to show how OzStruts solves the issue I think, where the previous doc wasn't clear enough. The modifications are; * number 4 in pain list section * re-wrote "Page Driven with OzStruts" section Also OzStruts is updated to support PRG pattern with samples. This is my first time to use this, and it work very nicely, I like this. The new doc is available at http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334 And new OzStruts is available at http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=128965 Regards, Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Craig McClanahan wrote in <[EMAIL PROTECTED]> >> I think page-driven development frameworks would exacerbate this problem >> unless they clarify with eloquence up-front how to make a clear >> seperation of the POST processing from the page preparation required for >> the next page. >> > >Yep, that is definitely a key point. Here is why Shale's view >controller helps you do that. The key point is this: > > The initialization code for any page (no matter how you got there) > goes in the prepare() method of the corresponding ViewController. > >The only thing you should do in the action method for processing a >request is to perform the necessary business transaction (save a >record to the database or whatever), then return the outcome code used >for navigation. The next page is responsible for taking care of >itself. > >Simple enough? > I agree with Craig. OzStruts does same thing for you with OzPage.prepareRequiredProperties() even on the curent verion of Struts. then codes will be like what Craig mentioned above. Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Rick, Thanks for the feedback. Your point is pre-population, right? Rick Reumann wrote in <[EMAIL PROTECTED]> >1) I have a DispatchAction that handles related functionality to a >particular task at hand... related CRUD stuff... ie. getEmployees, >updateEmployee, getEmployee etc. There is also a setUp method that >usually doesn't do anything more than call the prep() method in step 3 >below. > This is not page-driven programming for me, and it could be structural code with many switch (if) statement? >2) I don't bother having validation take place automatically. It's >cleaner and easier to maintain by just calling form.validate() from you >particular dispatch method. (You can still use the validation.xml stuff.) > >3) Each DispatchActon usually has a simple prep(..) or setup() method >that you can call to prep your form with any request objects it needs to >have handy (any Lists for drop downs etc). (If validation fails, call it >before returning to the form). > I would like pre-population task more consistence by framework. And I want exisiting Validation framework nicely with it. Not using Validation framework is your choice. >I guess some could argue that the Action class shouldn't have to take >care of preping the view, but to me it's not that big of a deal and on >the flip side you get to stay with the concept of just using Struts 'as >is' out of the box so it's easy for any new developer to follow. I'm all >for tweaking and modifying where necessary, but the above steps seem to Again, I would like prepare task for destination page more consistence. >cover 98% of the simple flow of web applications. There are exceptions >of course, but they aren't that difficult to work around. > Yes, you can do pre-population stuff with current Struts, and if you like that coding, that's fine. I'm not saying that we cannot do this. But I don't like that style as I mentioned in the article, and want to have more consistence way by framework with page-driven programming. If you don't like page-driven, it's your choice. but I would like to know the reason. Someone pointed me to see Echo project for the reason. Regards, Tak -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Bill, >pass information from the browser to the Action. You shouldn't use >ActionForms to pass arbitrary data from java code to JSP code, except >for pre-populating form fields.) Could you please explain with example for this? I'm not sure what "pass arbitrary data from java code to JSP code" means? >Regarding struts-config.xml: in OzStruts, it's too bad that you have to >register OzPage (ActionForm) and register Listener (Action) separately. >Conceptually, they are the same thing, right? I just want to say No, Page registration and listener registration is different. And I don't think it's so bad, becasue I didn't change anything from Struts. Page registration is Form registration. Listener registration is action definition. something like this: > > input="/webpage/ozstruts/vendor/addVendor.jsp" > >type="net.sourceforge.optionzero.ozstruts.sample.webapp.ozstruts.vendor.AddVendorPage"> > path="/webpage/ozstruts/vendor/vendorDetail.jsp"/> > path="/webpage/ozstruts/vendor/addVendor.jsp"/> > > I guess this defines corresponding JSP as input, and defines possible transition pages from it. But we need to use this in action mapping, but how? I'm sorry it's little difficult to me. Anyway, thanks so much for your feedback. Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Hi Bill, >Then AddVendorAction takes AddVendorForm as input, and then creates a >DisplayVendorDetailForm in the request context before forwarding to >displayVendor.jsp. Thanks for your feedback. You're right, but you're doing it by yourself in application code. This is one of the main idea of OzStruts. And I think this task should be done by framework, which makes applicaitn code consistence. In Struts, the framework only makes AddVendorForm available to vendorDetail.jsp. In OzStruts, you don't have to set DisplayVendorDetailForm into request attribute manually. Btw, I don't think it's normal practice in exisiting Struts application development, or I just misunderstood the reality of the Struts development. Page-driven programming is also important to me, because I don't want to see struts-config to maintain the code. To make this concept into code, I don't want to see request.setAttribute() in my application codes. In validation error transition, pre-population is also a key feature of OzStruts. You can say you can do it in each Action calss or some other techique. But I also would like to have consistence way by framework, then prepareRequiredProperties() with transitionContext object is there. I guess it's similar to prepare() method in Shale. Thanks, Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Joe Germuska wrote in <[EMAIL PROTECTED]> >am finding that a limitation. I would like a clean facility for >prepopulating forms from system data which interoperates with the >existing mechanism for prepopulating forms when validation fails and >the user must try again. I would also like a clean mechanism for >doing certain kinds of page preparation based on the destination page >rather than the processing action. I feel that this cleans things up I leave JSF discussion to experts. But what Joe would like is exactly OzStruts features on current Struts. Each OzPage must have prepareRequiredProperties method. This method in destinaiton OzPage instance will be called right before Struts dispatchs the JSP page, including validation error transition. The example code with validation is in OzStruts sample applicatin in the distribution. Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Bill, Thanks for the feedback. I should re-write this, it's not clear. >> Here is an example from OzStruts sample application. VendorDetail.jsp >> has two >> source pages, one is vendorSearch.jsp, and another is addVendor.jsp. In >> addVendor.jsp to vendorDeatil.jsp transition, ActionForm must have >> properties to >> get http request from addVendor.jsp, and rendering properties for >> vendorDeatil.jsp >> and addVendor.jsp for error. Thus ActionForm will have properties for >> two pages. >> On the other hand, the transition from vendorSearch.jsp is just http >> link with single >> destination page, so ActionForm don稚 have to consolidate properties >> for the two >> pages. It looks hard for junior developers isn稚 it? > >***Are you saying that (in normal Struts) the "submit" button for >vendorSearch.jsp and the "submit" button for addVendor.jsp both call the >same Action (and the same ActionForm)? > No, it's different. What I would like to say is, to select the ActionForm on mapping depends on how many destination page on the http request. vendorSearch.jsp just has a link to display vendorDeatil.jsp. In this single destination case, we use the ActionForm that has properties to render destination page (vendorDeatil.jsp), and don't have to have any propertis to render source page (vendorSearch.jsp). The a action is ShowVendorDetailAction with VendorForm, we don't need VendorSearchForm. addVendor.jsp has a "submit" button to send with parameters to create a Vendor, and application routes to vendorDetail.jsp when it's sucsessfuly done. It also routes to addVendor.jsp when it's failed to add or validation errors. In this multiple destination case, the ActionForm must have properties to render all the destination pages (both vednorDetail.jsp and addVendor.jsp). The a action is AddVendorAction with VendorForm. And now VendorForm gets fat. Tak -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Craig, Thank you so much for useful information about Struts in the future. I didn't know that Struts 2.0 will support Page oriented programming, and am also surprised that Shale View Controller has simillar features that OzStruts does. What I want to have on OzStruts are 1:Page oriented programming without Action and ActoinForm maze. 2:Consistent pre-population sequence, even on the validation error page transition. I would like to understand "Shale" on these topics correctly. 1:Is action still required? intead of having event handler it in View object? It looks like listeners are in each ViewController class in example. I guess, I should study JSF first. please forget about this. 2:Will View Controller's prepare() be called even on validation error transition? because this is the most ugly part of current Struts. 3:How to pass transition context information from View object responded http resurst to View object being rendered? As others asked, the release timing is very important for us. Please let us know the sachedule of "Shale"? , and where we can post the question related "Shale"? this mailing list? And I am convinced that OzStruts is still useful add-on, until JSF get popular. Regards, Tak Craig McClanahan wrote in <[EMAIL PROTECTED]> >Tak, > >You and others who like the page oriented development environment will >enjoy reading about "Shale" -- it's my proposed architecture for >Struts 2.0 (basically providing application controller features on top >of JavaServer Faces), and the ViewHandler API has many of the same >characteristics you are describing. > >The proposal isn't packaged separately at the moment, but it's all in >the *source* nightly builds of Struts, available at: > > http://cvs.apache.org/builds/jakarta-struts/nightly/ > >In the distro, the directory "contrib/struts-shale" includes a >proposal document and the beginnings of the corresponding API classes >and implementations, while the "contrib/struts-shale-mailreader >contains the good old struts-example webapp converted to use this >style to make it easy to see what it does to the programming model. > >Of course, we're not the only ones thinking this way, either -- >ASP.Net has pretty much the same pattern with code behind files. > >Craig -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A new paradigm of Struts development
Hi Adam, Thanks for your interest on OzStruts. Adam Hardy wrote in <[EMAIL PROTECTED]> >tak, >read the pdf intro and i'm still in the dark about what ozstruts >actually does. I appreciate all of the problem spots you highlight in >struts, but it's really not clear how your page-driven classes overcome >them all. > My apology, it's because of my poor English, I guess. Two key features from OzStruts are 1: Page oriented programming without Action and ActoinForm maze. 2: Consistent pre-population sequence, even on the validation error transition. >For instance, you want to look up the action class. You have to go >through the struts-config.xml anyway to get the class for the URL. What >difference does ozstruts make there? That's just the first point. I see In OzStruts, all the event handlers, I say listeners, are in Page class, which represents JSP page, and only one Aciton class in OzStruts application. Lookling up the action for given URL path in classic appproach is equivalent to lookup a listener method in Page class. Scince the listener name is in URL path, you don't have to see struts-config at all. >how there might be some interesting pattern implementations in the way >the page classes communicate to mask 'transitions', but it's not clear >at all how. > You'll see this details Developer Guide and sample application code. Developer Guide includes sequence diagram, too. Also OzStruts is very samll, so you can trace codes in 10 min. I hope this document makes you clear, Tak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A new paradigm of Struts development
Hi, I would like to introduce Page Driven development, OzStruts, to all Struts developers, which makes Struts application more clean and maintainable. I guess most of Struts developers are having same issues I had, so please take a look at my two cent idea. Any productive suggestion and critices would be really appreciated. Documentations are available at http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=120334&release_id=280886 OzStruts 1.0 is available at http://sourceforge.net/project/showfiles.php?group_id=111296&package_id=128965&release_id=280994 -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
