Re: Basic CRUD
- Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 29, 2003 9:48 PM Subject: Re: Basic CRUD Maybe in 3rd world countries this works, maybe you should spend a few $ with IP Lawyer? You can't make generalization because some open source license requires attribution (this was built using) , or licensing in kind (they own your source), or are only for non commercial use or worse. Anyway, if netspread becomes big enough to sue This will be a good e-mail to use to establish MO. Here is my Algorithms, here it is at NetSpread, and here is my license. Just back and find this thread had gone too far from its original subject. As a lead algorithm engineer with published algorithms on IEEE Transactions and a United States patent granted in 1999, I feel lucky I did not work with 3rd class instructors who do not understand basic research principles. Open source is rarely artistic license. Only artistic license I recall is Doug Lea's fast threaded collections. Any license term can not privide *all* things to *all* people, just like a framework can not do *all* things for *all* people, regardless it is artistic or not. Carrier production license will be designed to encourage smart people to develop advanced algorithms and publish them too. Jing .V [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 22:04:36 -, Eric Miles [EMAIL PROTECTED] wrote : Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Here are what I did before I created the *general* CRUD algorithm: Performed serious research on existing CRUD algorithms from several vendors, published articles, and mailing lists. Then started to design a *superior* version of my own. I am not worried about vendors will sue me at all because I know it is my own work and I am grateful to those who published their algorithms so that I can design a *better* one. Making my algorithms available in this mailing list is not just for *you*, it is for ones who want to find their own *better* solutions. Innovations benefit from sharing ideas. That is my point of view. If anyone believes he/she has to license a product to get an idea, That is fundamentally wrong if that idea or algorithm has not been patented yet(Stop! this subject is not about license:-) Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Of course, you are welcome to publish your ideas or algorithms! Jing Thanks for the feedback. -Eric -- Vic Cekvenich, Struts Instructor, 1-800-917-JAVA Advanced a href =baseBeans.comStruts Training/a and project recovery in North East. Open Source a href =baseBeans.comContent Management/a basicPortal sofware Best practicea href =baseBeans.comStruts Support/a v.1.1 helper ScafflodingXPress - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic CRUD
I ended up using links instead. I have a links alongside each record with parameters action and record key for UPDATE, READ, DELETE. And then I have an Add button at the bottom of my form to do the CREATE action. I think I would rather have links than buttons (IMO they look nicer and fit better) and therefore I avoid JavaScript. Cheers Shane -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Sunday, 1 June 2003 2:24 p.m. To: [EMAIL PROTECTED] Subject: Re: Basic CRUD Problem solved. Basically, I added a hidden form property called 'key' that gets set during the onclick event of either the 'update' or 'delete' buttons. I used the nested taglib from the keyboardmonkey, making things easier to update the collection. I used 1 form in the jsp. I used bean:define to capture the primary key id of the record during the iteration, which was passed to the javascript onclick event to set the hidden form parameter, 'key'. IMHO, the interaction with the javascript code is sloppy. Hopefully, something is in the works to clean this up. I believe struts-el might do this, I don't know. The html taglib would not evaluate a bean:write tag within the onclick event. That's why I had to add the bean:define and a setKey() javascript function. If anyone is interested in more details, send me an email, or answer to this post and I'll post the details. Thanks. -Eric --- In [EMAIL PROTECTED], Eric Miles [EMAIL PROTECTED] wrote: Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Thanks for the feedback. -Eric --- In [EMAIL PROTECTED], Andrew Hill [EMAIL PROTECTED] wrote: Yeh, alright. Fair enough. So your license does allow him to extract that particular code out of the Carrier source , and use it in his own product without having to join the Carrier group etc... if he wants to distribute whatever it is he is writing? -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 13:36 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Basic CRUD - Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations
Re: Basic CRUD
Problem solved. Basically, I added a hidden form property called 'key' that gets set during the onclick event of either the 'update' or 'delete' buttons. I used the nested taglib from the keyboardmonkey, making things easier to update the collection. I used 1 form in the jsp. I used bean:define to capture the primary key id of the record during the iteration, which was passed to the javascript onclick event to set the hidden form parameter, 'key'. IMHO, the interaction with the javascript code is sloppy. Hopefully, something is in the works to clean this up. I believe struts-el might do this, I don't know. The html taglib would not evaluate a bean:write tag within the onclick event. That's why I had to add the bean:define and a setKey() javascript function. If anyone is interested in more details, send me an email, or answer to this post and I'll post the details. Thanks. -Eric --- In [EMAIL PROTECTED], Eric Miles [EMAIL PROTECTED] wrote: Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Thanks for the feedback. -Eric --- In [EMAIL PROTECTED], Andrew Hill [EMAIL PROTECTED] wrote: Yeh, alright. Fair enough. So your license does allow him to extract that particular code out of the Carrier source , and use it in his own product without having to join the Carrier group etc... if he wants to distribute whatever it is he is writing? -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 13:36 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Basic CRUD - Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations. Some we do it on the same page, some we do it on different page in the demo. There are total of 39 pages just for this demo with nested level up to 5. This demo is done exclusively within Struts. No javascript! Even there is no custom code for this demo. You compose the Ant Project Configuration as hyper action wizards completely within Carrier rich client. And any submited forms will be automatically persisted and restored for you as necessary. The algorithms
Re: Basic CRUD
The html taglib would not evaluate a bean:write tag within the onclick event. That's why I had to add the bean:define and a setKey() javascript function. Do you mean something like this didn't work: html:form onclick=bean:write.../... ? That's invalid JSP syntax and is not a defect in the html taglib or any other JSP taglib, the page compiler just won't compile it. You may have meant something else though... David If anyone is interested in more details, send me an email, or answer to this post and I'll post the details. Thanks. -Eric --- In [EMAIL PROTECTED], Eric Miles [EMAIL PROTECTED] wrote: Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Thanks for the feedback. -Eric --- In [EMAIL PROTECTED], Andrew Hill [EMAIL PROTECTED] wrote: Yeh, alright. Fair enough. So your license does allow him to extract that particular code out of the Carrier source , and use it in his own product without having to join the Carrier group etc... if he wants to distribute whatever it is he is writing? -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 13:36 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Basic CRUD - Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations. Some we do it on the same page, some we do it on different page in the demo. There are total of 39 pages just for this demo with nested level up to 5. This demo is done exclusively within Struts. No javascript! Even there is no custom code for this demo. You compose the Ant Project Configuration as hyper action wizards completely within Carrier rich client. And any submited forms will be automatically persisted and restored for you as necessary. The algorithms that makes this happen is called Wheels. When you download Carrier at www.netspread.com, the source codes for the Wheels will be available for you. Jing -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Basic CRUD
Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Thanks for the feedback. -Eric --- In [EMAIL PROTECTED], Andrew Hill [EMAIL PROTECTED] wrote: Yeh, alright. Fair enough. So your license does allow him to extract that particular code out of the Carrier source , and use it in his own product without having to join the Carrier group etc... if he wants to distribute whatever it is he is writing? -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 13:36 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Basic CRUD - Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations. Some we do it on the same page, some we do it on different page in the demo. There are total of 39 pages just for this demo with nested level up to 5. This demo is done exclusively within Struts. No javascript! Even there is no custom code for this demo. You compose the Ant Project Configuration as hyper action wizards completely within Carrier rich client. And any submited forms will be automatically persisted and restored for you as necessary. The algorithms that makes this happen is called Wheels. When you download Carrier at www.netspread.com, the source codes for the Wheels will be available for you. Jing - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic CRUD
On Thu, 29 May 2003 22:04:36 -, Eric Miles [EMAIL PROTECTED] wrote : Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Here are what I did before I created the *general* CRUD algorithm: Performed serious research on existing CRUD algorithms from several vendors, published articles, and mailing lists. Then started to design a *superior* version of my own. I am not worried about vendors will sue me at all because I know it is my own work and I am grateful to those who published their algorithms so that I can design a *better* one. Making my algorithms available in this mailing list is not just for *you*, it is for ones who want to find their own *better* solutions. Innovations benefit from sharing ideas. That is my point of view. If anyone believes he/she has to license a product to get an idea, That is fundamentally wrong if that idea or algorithm has not been patented yet(Stop! this subject is not about license:-) Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Of course, you are welcome to publish your ideas or algorithms! Jing Thanks for the feedback. -Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic CRUD
Maybe in 3rd world countries this works, maybe you should spend a few $ with IP Lawyer? You can't make generalization because some open source license requires attribution (this was built using) , or licensing in kind (they own your source), or are only for non commercial use or worse. Anyway, if netspread becomes big enough to sue This will be a good e-mail to use to establish MO. Here is my Algorithms, here it is at NetSpread, and here is my license. Open source is rarely artistic license. Only artistic license I recall is Doug Lea's fast threaded collections. .V [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 22:04:36 -, Eric Miles [EMAIL PROTECTED] wrote : Chicks that don't lay eggs are still good for cooking, eh? ;-) Jing, Your source code is Open Source licensing, right? Not going to sue me when I resell or make $$$ off your code?!? Here are what I did before I created the *general* CRUD algorithm: Performed serious research on existing CRUD algorithms from several vendors, published articles, and mailing lists. Then started to design a *superior* version of my own. I am not worried about vendors will sue me at all because I know it is my own work and I am grateful to those who published their algorithms so that I can design a *better* one. Making my algorithms available in this mailing list is not just for *you*, it is for ones who want to find their own *better* solutions. Innovations benefit from sharing ideas. That is my point of view. If anyone believes he/she has to license a product to get an idea, That is fundamentally wrong if that idea or algorithm has not been patented yet(Stop! this subject is not about license:-) Although, Carrier looks like a nice product, my hope was to do the grunt work myself, to get a feel for persisting objects through struts and to do it via several methods. Once I can get the correct object from the view to the action, everything should work nice. On the backend, I'm persisting objects by using a stateless session EJB talking to Hibernate. Plus, using XDoclet is the best thing since Ant. I'll post back when I get this thing hammered out. Of course, you are welcome to publish your ideas or algorithms! Jing Thanks for the feedback. -Eric -- Vic Cekvenich, Struts Instructor, 1-800-917-JAVA Advanced a href =baseBeans.comStruts Training/a and project recovery in North East. Open Source a href =baseBeans.comContent Management/a basicPortal sofware Best practicea href =baseBeans.comStruts Support/a v.1.1 helper ScafflodingXPress
RE: Basic CRUD
Hi Eric
I do not know if what I can provide will help. I have only been using
Struts for a month. Your post was almost identical to one I was about to
send so I was hoping to see some replies to yours.
Anyhow what I have so far is this (an Edit):
[I refer to a Distribution Channel entity which has a Name and Bank Account.
Name is the PK of this entity]
I have a jsp page called Customer Maintenance.
It lists the customers in a table like:
DISTRIBUTION CHANNEL NAME ACTION
Bob Edit
BillEdit
Sam Edit
The Edit button is an Image and I am using Struts ImageButtonBean as
outlined in Ted's Strus tips at www.husted.com.
What I have just got to *that works* is this:
logic:iterate id=channel name=DistributionChannelMaintenanceBean
property=distributionChannels
trhtml:form action=/DistributionChannelMaintenance
td align=left
bean:write name=channel property=name
filter=true/
/td
td align=center
html:image
src=http://localhost/ims/images/goButton.gif; property=editButton /
/td
html:hidden name=channel property=name /
/html:form/tr
/logic:iterate
The DistributionChannelMaintenanceBean has a collection of the Distribution
Channels that I iterate thru writing my table. I am also creating a form
around each record with the hidden tag storing the value of the
distribution name.
When I submit the form with Edit button, my Action class gets the
Distribution Name value and sets a session attribute
(distributionChannelName) and forwards to my edit page (which will also do
create/add later).
String distributionChannelName = request.getParameter(name);
request.getSession().setAttribute(distributionChannelName,
distributionChannelName);
return mapping.findForward(FORWARD_edit);
The FORWARD_edit ends up going to the
path=/EditDistributionChannel.do?action=Edit
In the Action class I do:
String action = request.getParameter(action);
if (Edit.equals(action))
{
String distributionChannelName = (String)
request.getSession().getAttribute(distributionChannelName);
DistributionChannel distributionChannel =
DistChannelManager.get().getDistributionChannel(distributionChannelName);
editDistributionChannelBean.setName(distributionChannel.getName());
editDistributionChannelBean.setCmaBankAccount(distributionChannel.getCmaBank
Account());
editDistributionChannelBean.setProducts(distributionChannel.getAllProducts()
);
return mapping.findForward(FORWARD_create);
}
So that is where I am currently. I may have done some *ugly* things at this
stage because this is a change from having an Edit page where a selector box
displayed the distribution channels to edit and the Create came from another
page. Create will (soon) some from my new Distribution Channel maintenance
page.
I guess where this may help you is in using a form for each record.
Anyhow if I can be of any help let me know and if you find anything that you
think I would find helpful please let me know.
Cheers
Shane
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 28 May 2003 3:02 p.m.
To: [EMAIL PROTECTED]
Subject: Basic CRUD
I am putting together a simple web app that performs CRUD operations on a
database table. The web app consists of 1 jsp page which handles all CRUD
actions. The first part of the page contains a form with 2 fields and
'create' and 'retrieve' buttons. Both these functions work fine. When a
'retrieve' (select id,field1,field2 from table1) is done, a table is
rendered with the resultset on the same page. For each record of the
recordset, there exists an 'update' and 'delete' button. The problem is
how do I tell my action class which record to act on?
class MyFormBean extends ActionForm {
private MyBean myBean;
private ArrayList myBeanList;
}
class MyBean {
private Long id;
private String field1;
private String field2;
}
The idea is to manage this 1 particular db table from a single view with a
single action class extended from LookupDispatchAction. I've tried
several ways with no success. I've tried using 1 form that includes
everything. I've tried using a form for each record. I've tried using
the nested taglib. I believe this is view/jsp/taglib problem since the
actions are firing correctly. How can I populate 'myBean' with the data
of the corresponding record from which the 'update' or 'delete' buttons
were clicked?
I prefer not to use checkboxes with a global 'update' and 'delete' button.
I prefer not to use javascript (I'm not a big fan of this scripting
language and only use it when absolutely necessary, which is rare). I
prefer not to go to a second page to edit.
Can this be done exclusively within Struts?
Thanks in
Re: Basic CRUD
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 28 May 2003 3:02 p.m.
To: [EMAIL PROTECTED]
Subject: Basic CRUD
I am putting together a simple web app that performs CRUD operations on a
database table. The web app consists of 1 jsp page which handles all CRUD
actions. The first part of the page contains a form with 2 fields and
'create' and 'retrieve' buttons. Both these functions work fine. When a
'retrieve' (select id,field1,field2 from table1) is done, a table is
rendered with the resultset on the same page. For each record of the
recordset, there exists an 'update' and 'delete' button. The problem is
how do I tell my action class which record to act on?
The difficulty of this kind of problems is that there is no *standard* way
to
handle CRUD operations in general. However, the just unveiled Carrier
allows you to visually compose hyper action wizards. In particular, the
demo for the Ant Project Configuration has a lot of CRUD operations.
If I understand your business problem, here is a very similar situation:
an Ant project may contain several targets, so there are CRUD operations
on the targets. For each target, there are several tasks. So we have
CRUD operations on the tasks. For each task, there might be several
nested attributes, so more CRUD operations. Some we do it on the
same page, some we do it on different page in the demo. There are
total of 39 pages just for this demo with nested level up to 5.
This demo is done exclusively within Struts. No javascript! Even
there is no custom code for this demo. You compose
the Ant Project Configuration as hyper action wizards completely
within Carrier rich client. And any submited forms will be automatically
persisted and restored for you as necessary.
The algorithms that makes this happen is called Wheels. When you
download Carrier at www.netspread.com, the source codes for the
Wheels will be available for you.
Jing
class MyFormBean extends ActionForm {
private MyBean myBean;
private ArrayList myBeanList;
}
class MyBean {
private Long id;
private String field1;
private String field2;
}
The idea is to manage this 1 particular db table from a single view with a
single action class extended from LookupDispatchAction. I've tried
several ways with no success. I've tried using 1 form that includes
everything. I've tried using a form for each record. I've tried using
the nested taglib. I believe this is view/jsp/taglib problem since the
actions are firing correctly. How can I populate 'myBean' with the data
of the corresponding record from which the 'update' or 'delete' buttons
were clicked?
I prefer not to use checkboxes with a global 'update' and 'delete' button.
I prefer not to use javascript (I'm not a big fan of this scripting
language and only use it when absolutely necessary, which is rare). I
prefer not to go to a second page to edit.
Can this be done exclusively within Struts?
Thanks in advance.
-Eric
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic CRUD
Mate, that answer is about as useful as a chook that doesnt lay eggs.
If you go answering peoples _struts_ questions on the _struts list_ by
carping on about how great some product of yours is then you will make
yourself unpopular very quickly.
-Original Message-
From: Jing Zhou [mailto:[EMAIL PROTECTED]
Sent: Thursday, 29 May 2003 12:43
To: Struts Users Mailing List
Subject: Re: Basic CRUD
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 28 May 2003 3:02 p.m.
To: [EMAIL PROTECTED]
Subject: Basic CRUD
I am putting together a simple web app that performs CRUD operations on a
database table. The web app consists of 1 jsp page which handles all CRUD
actions. The first part of the page contains a form with 2 fields and
'create' and 'retrieve' buttons. Both these functions work fine. When a
'retrieve' (select id,field1,field2 from table1) is done, a table is
rendered with the resultset on the same page. For each record of the
recordset, there exists an 'update' and 'delete' button. The problem is
how do I tell my action class which record to act on?
The difficulty of this kind of problems is that there is no *standard* way
to
handle CRUD operations in general. However, the just unveiled Carrier
allows you to visually compose hyper action wizards. In particular, the
demo for the Ant Project Configuration has a lot of CRUD operations.
If I understand your business problem, here is a very similar situation:
an Ant project may contain several targets, so there are CRUD operations
on the targets. For each target, there are several tasks. So we have
CRUD operations on the tasks. For each task, there might be several
nested attributes, so more CRUD operations. Some we do it on the
same page, some we do it on different page in the demo. There are
total of 39 pages just for this demo with nested level up to 5.
This demo is done exclusively within Struts. No javascript! Even
there is no custom code for this demo. You compose
the Ant Project Configuration as hyper action wizards completely
within Carrier rich client. And any submited forms will be automatically
persisted and restored for you as necessary.
The algorithms that makes this happen is called Wheels. When you
download Carrier at www.netspread.com, the source codes for the
Wheels will be available for you.
Jing
class MyFormBean extends ActionForm {
private MyBean myBean;
private ArrayList myBeanList;
}
class MyBean {
private Long id;
private String field1;
private String field2;
}
The idea is to manage this 1 particular db table from a single view with a
single action class extended from LookupDispatchAction. I've tried
several ways with no success. I've tried using 1 form that includes
everything. I've tried using a form for each record. I've tried using
the nested taglib. I believe this is view/jsp/taglib problem since the
actions are firing correctly. How can I populate 'myBean' with the data
of the corresponding record from which the 'update' or 'delete' buttons
were clicked?
I prefer not to use checkboxes with a global 'update' and 'delete' button.
I prefer not to use javascript (I'm not a big fan of this scripting
language and only use it when absolutely necessary, which is rare). I
prefer not to go to a second page to edit.
Can this be done exclusively within Struts?
Thanks in advance.
-Eric
-
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]
-
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]
Re: Basic CRUD
- Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations. Some we do it on the same page, some we do it on different page in the demo. There are total of 39 pages just for this demo with nested level up to 5. This demo is done exclusively within Struts. No javascript! Even there is no custom code for this demo. You compose the Ant Project Configuration as hyper action wizards completely within Carrier rich client. And any submited forms will be automatically persisted and restored for you as necessary. The algorithms that makes this happen is called Wheels. When you download Carrier at www.netspread.com, the source codes for the Wheels will be available for you. Jing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Basic CRUD
Yeh, alright. Fair enough. So your license does allow him to extract that particular code out of the Carrier source , and use it in his own product without having to join the Carrier group etc... if he wants to distribute whatever it is he is writing? -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 13:36 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: Basic CRUD - Original Message - From: Andrew Hill [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 9:57 PM Subject: RE: Basic CRUD Mate, that answer is about as useful as a chook that doesnt lay eggs. If you go answering peoples _struts_ questions on the _struts list_ by carping on about how great some product of yours is then you will make yourself unpopular very quickly. Have you ever thought someone might be interested in a *general* purpose CRUD algorithm? We got such an algorithm with its core codes open for every one. -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 12:43 To: Struts Users Mailing List Subject: Re: Basic CRUD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 May 2003 3:02 p.m. To: [EMAIL PROTECTED] Subject: Basic CRUD I am putting together a simple web app that performs CRUD operations on a database table. The web app consists of 1 jsp page which handles all CRUD actions. The first part of the page contains a form with 2 fields and 'create' and 'retrieve' buttons. Both these functions work fine. When a 'retrieve' (select id,field1,field2 from table1) is done, a table is rendered with the resultset on the same page. For each record of the recordset, there exists an 'update' and 'delete' button. The problem is how do I tell my action class which record to act on? The difficulty of this kind of problems is that there is no *standard* way to handle CRUD operations in general. However, the just unveiled Carrier allows you to visually compose hyper action wizards. In particular, the demo for the Ant Project Configuration has a lot of CRUD operations. If I understand your business problem, here is a very similar situation: an Ant project may contain several targets, so there are CRUD operations on the targets. For each target, there are several tasks. So we have CRUD operations on the tasks. For each task, there might be several nested attributes, so more CRUD operations. Some we do it on the same page, some we do it on different page in the demo. There are total of 39 pages just for this demo with nested level up to 5. This demo is done exclusively within Struts. No javascript! Even there is no custom code for this demo. You compose the Ant Project Configuration as hyper action wizards completely within Carrier rich client. And any submited forms will be automatically persisted and restored for you as necessary. The algorithms that makes this happen is called Wheels. When you download Carrier at www.netspread.com, the source codes for the Wheels will be available for you. Jing - 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]
