Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 9442 invoked from network); 28 Nov 2002 13:09:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Nov 2002 13:09:39 -0000 Received: (qmail 13005 invoked by uid 97); 28 Nov 2002 13:10:27 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 12960 invoked by uid 97); 28 Nov 2002 13:10:26 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 12948 invoked by uid 98); 28 Nov 2002 13:10:26 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: Re: Complicated Web Interfaces? From: Arron Bates To: Struts Users Mailing List In-Reply-To: <001901c2968e$9b4862d0$a60aa8c0@server1.etilize.com> References: <000e01c29686$735c0630$8e607c90@darthvader> <001901c2968e$9b4862d0$a60aa8c0@server1.etilize.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 29 Nov 2002 00:06:21 +1100 Message-Id: <1038488782.1277.62.camel@linux> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > I've also looked at the monkey-struts example as well but that seems to > > lack the > > creation of objects in these lists, which doesn't look to be a problem > > to implement > > but that might be an oversight on my part : ) please let me know if I'm > > wrong. Have another play, click on "new banana"... :) http://www.keyboardmonkey.com/StrutMonkey/MonkeyStruts_v2.jsp > KB-Monkey-example uses a fixed object model (i.e it knows what fields are > there in each object). However I think if you want the tree to be dynamic > you can use the same technique with your own object model (which seems to be > dynamic in content). The key to adding and deleting the nodes is the way the > button clicks of "Add" and "Delete" are handled in a nested environment. > Nested tags enable you to remember the context of added and deleted > objects/nodes. You can use Map-backed properties for dynamic form-fields. > > But one issue with the monkey example is that it refreshes the page if I > want to add/delete an object/node. Wouldn't it be more efficient to use > JavaScript for the purpose? I mean why resend the request back to the server > if you only want to add "blank" fields? If anybody has accomplished this I > would be glad to know. It's all up to watever you want to code. The fact that the monkey example trips to the server has nothing to do with the nested tags. To write the monkey example in Struts without the nested tags is verging on impossible, at the very least a truly large headache, it was really quite easy. If the nested tags are guilty of anything, they make it very easy (and even fun?... maybe I'm wired differently) to add more and more complexity to the structure. The nested tags have made some truly unwieldy applications, including the reason for their creation. You just have to ask yourself one question... Red or Blue pill? :P Arron. -- To unsubscribe, e-mail: For additional commands, e-mail: