Re: Work flow RFC
basically my company is working on a workflow app. to make sure that the workflow engine is interoperable, we follow the wfmc stds. XML plays a vital role in defining the process of a workflow. XML is also used to define organisation units, work list and other stuff. So base on these defined xml document type, the workflow engine interacts with all other application currently used in a company. For instance, if a bank is already using some application, the engine should be able to invoke the application for a particular user base on his accesslevel and permission defined in an xml doc. Hope this helps. I am also looking to hear from any one doing other workflow app too! Thanks XML is the future! Joshua Yip Software Developer IB-DOCS.COM Intelligent Business Document dot Com Office email: [EMAIL PROTECTED] Personal Email:[EMAIL PROTECTED] YahooID: joshuayip ICQ:8657630 - Original Message - From: "Jonathan Asbell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 11:16 AM Subject: Re: Work flow RFC > Well Josh, if you have an idea please share it. I am all ears. How would > you do workflow with xml? > > > - Original Message - > From: "Joshua Yip" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 10:53 PM > Subject: Re: Work flow RFC > > > > Are you trying to develop an workflow application using purely servlets > and > > jsp? > > > > XML is the future! > > > > Joshua Yip > > Software Developer > > IB-DOCS.COM > > Intelligent Business Document dot Com > > Office email: [EMAIL PROTECTED] > > Personal Email:[EMAIL PROTECTED] > > YahooID: joshuayip > > ICQ:8657630 > > > > - Original Message - > > From: "Ted Husted" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, June 06, 2001 12:48 AM > > Subject: Re: Work flow RFC > > > > > > > I'm still fuzzy on the mechanism we would use to represent and enforce > > > the workflow. There has been mention of things like command tokens, but > > > are any code samples available. > > > > > > Can anyone explain how Barracuda implements their workflow, and whether > > > it could be mapped to the Struts Actions/ActionMappings model? > > > > > > I believe Barracuda and Struts are complementary in most ways, and it > > > would be in our best interest to adopt and adapt rather than > > > roll-our-own, if feasible. > > > > > > Jonathan wrote: > > > > > > > > Again, Ive got to say look at the Barracuda project. They have one of > > these > > > > gui configurers. Check it out at > > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > >
Re: Work flow RFC
Well Josh, if you have an idea please share it. I am all ears. How would you do workflow with xml? - Original Message - From: "Joshua Yip" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 10:53 PM Subject: Re: Work flow RFC > Are you trying to develop an workflow application using purely servlets and > jsp? > > XML is the future! > > Joshua Yip > Software Developer > IB-DOCS.COM > Intelligent Business Document dot Com > Office email: [EMAIL PROTECTED] > Personal Email:[EMAIL PROTECTED] > YahooID: joshuayip > ICQ:8657630 > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 06, 2001 12:48 AM > Subject: Re: Work flow RFC > > > > I'm still fuzzy on the mechanism we would use to represent and enforce > > the workflow. There has been mention of things like command tokens, but > > are any code samples available. > > > > Can anyone explain how Barracuda implements their workflow, and whether > > it could be mapped to the Struts Actions/ActionMappings model? > > > > I believe Barracuda and Struts are complementary in most ways, and it > > would be in our best interest to adopt and adapt rather than > > roll-our-own, if feasible. > > > > Jonathan wrote: > > > > > > Again, Ive got to say look at the Barracuda project. They have one of > these > > > gui configurers. Check it out at > > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event >
Re: Work flow RFC
Are you trying to develop an workflow application using purely servlets and jsp? XML is the future! Joshua Yip Software Developer IB-DOCS.COM Intelligent Business Document dot Com Office email: [EMAIL PROTECTED] Personal Email:[EMAIL PROTECTED] YahooID: joshuayip ICQ:8657630 - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 06, 2001 12:48 AM Subject: Re: Work flow RFC > I'm still fuzzy on the mechanism we would use to represent and enforce > the workflow. There has been mention of things like command tokens, but > are any code samples available. > > Can anyone explain how Barracuda implements their workflow, and whether > it could be mapped to the Struts Actions/ActionMappings model? > > I believe Barracuda and Struts are complementary in most ways, and it > would be in our best interest to adopt and adapt rather than > roll-our-own, if feasible. > > Jonathan wrote: > > > > Again, Ive got to say look at the Barracuda project. They have one of these > > gui configurers. Check it out at > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
Re: Work flow RFC
Hello Incze and all, There are a few efforts going that the group here might want to consider as well. First there has been more work done with the WfMC that you should be aware of. Very recently the WfMC released a draft version 0.03a of the XPDL (Workflow Process Definition Interface) you can take a look at it here. http://www.wfmc.org/standards/docs.htm Additionally there is another effort by another organization, BPMI, you can take a look here at http://www.BPMI.org The BPMI has a draft release for workflow/business process definitions called the BPML (Business Process Modeling Language). IBM's spec contains features that are included in both of these efforts with a web services slant, however it requires another specification which is not released yet - WSEL. HIH, john At 01:47 AM 6/6/2001 +0200, Incze Lajos wrote: On Tue, Jun 05, 2001 at 11:46:58AM -0700, Frye, Dave wrote: > Keep in mind that Microsoft uses there own version of DTDs and XML Schemas > that are not W3C conformant. You would then have to use their XSL tools, > which, of course, would be Wintel-based. This would not make for a very > platform independent solution... > I know of two Workflow DTD's. The one seems to be emerging beeing a strategic element for the IBM web services effort (altough the DTD is open). It is the WSFL (Web Services Flow Language - http://www-4.ibm.com/software/solutions/webservices/resources.html) which is pretty general, and an even more general one from the W3C submissions, XTND (XML Transition Network Definition http://www.w3.org/TR/xtnd/ ). There was an "official" workflow standard initiative some years ago, but it became really big (see www.wfmc.org for the Workflow Management Coalition). Don't think these would give "the" solution, but (mainly the IBM spec) provide a good vocabulary. incze
Re: Work flow RFC
On Tue, Jun 05, 2001 at 11:46:58AM -0700, Frye, Dave wrote: > Keep in mind that Microsoft uses there own version of DTDs and XML Schemas > that are not W3C conformant. You would then have to use their XSL tools, > which, of course, would be Wintel-based. This would not make for a very > platform independent solution... > I know of two Workflow DTD's. The one seems to be emerging beeing a strategic element for the IBM web services effort (altough the DTD is open). It is the WSFL (Web Services Flow Language - http://www-4.ibm.com/software/solutions/webservices/resources.html) which is pretty general, and an even more general one from the W3C submissions, XTND (XML Transition Network Definition http://www.w3.org/TR/xtnd/ ). There was an "official" workflow standard initiative some years ago, but it became really big (see www.wfmc.org for the Workflow Management Coalition). Don't think these would give "the" solution, but (mainly the IBM spec) provide a good vocabulary. incze
Making over Half Million Dollars every 4 to 5 Months from your Home
AS SEEN ON NATIONAL TV:Making over Half Million Dollars every 4 to 5 Months from your Home for an investment of only$25 U.S. Dollars expense one timeTHANK'S TO THE COMPUTER AGE AND THE INTERNET!==BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!Before you say ''Bull'', please read the following.This is the letter you have been hearing about on the news lately. Due to the popularityof this letter on the Internet, a national weekly news program recently devoted an entireshow to the investigation of this program described below, to see if it really can makepeople money. The show also investigated whether or not the program was legal. Their findingsproved once and for all that there are ''absolutely NO Laws prohibiting the participation inthe program and if people can follow the simple instructions, they are bound to make somemega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY& RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER.This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times beforebut each time I passed on it. I am so glad I finally joined just to see what one could expectin return for the minimal effort and money required. To my astonishment, I receivedtotal $610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey.===Here is another testimonial: "This program has been around for a long time but I never believedin it. But one day when I received this again in the mail I decided to gamble my $25 on it. Ifollowed the simple instructions and 3 weeks later the money started to come in.First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00.So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I amplaying it again. The key to success in this program is to follow the simple steps and NOT changeanything.'' More testimonials later but first,= PRINT THIS NOW FOR YOUR FUTURE REFERENCE ==$If you would like to make at least $500,000 every 4 to 5 months easily And comfortably, pleaseread the following...THEN READ IT AGAIN and AGAIN!!!$FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE,GUARANTEED!INSTRUCTIONS:=Order all 5 reports shown on the list below =For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING andYOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mailproblems.=== When you place your order, make sure you order each of the 5 reports.You will need all 5 reports so that you can save them on your computer and resell them.YOUR TOTAL COST $5 X 5=$25.00.Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals.Save them on your computer so they will be accessible for you to send to the 1,000's of peoplewho will order them from you. Also make a floppy of these reports and keep it on your desk incase something happen to your computer.IMPORTANT - DO NOT alter the names of the people who are listed next to each report, ortheir sequence on the list, in any way other than what is instructed below in step'' 1 through 6 '' or you will lose out on majority of your profits. Once you understandthe way this works, you will also see how it does not work if you change it. Remember, thismethod has been tested, and if you alter, it will NOT work !!! People have tried to put theirfriends/relatives names on all five thinking they could get all the money. But it does notwork this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Nottry to change anything other than what is instructed. Because if you do, it will not work foryou. Remember, honesty reaps the reward!!!1 After you have ordered all 5 reports, take this advertisement and REMOVE thename & address of the person in REPORT # 5. This person has made it through the cycle andis no doubt counting their fortune.2 Move the name & address in REPORT # 4 down TO REPORT # 5.3 Move the name & address in REPORT # 3 down TO REPORT # 4.4 Move the name & address in REPORT # 2 down TO REPORT # 3.5 Move the name & address in REPORT # 1 down TO REPORT # 26 Insert YOUR name & address in the REPORT # 1 Position.PLEASE MAKE SURE you copy every name & address ACCURATELY!== Take this entire letter, with the modified list of names, and save it on your computer.DO NOT MAKE ANY OTHER CHANGES.Save this on a disk as well just in case you lose any data. To assist you wit
Need help ! Struts on Resin1.3
Title: Need help ! Struts on Resin1.3 Hi Folks Can some body help me on deploying Struts .war file on Resin1.3 ??? I tried puting the .war file on webapps directory but gives me error. Thanks Jiten Software Engineer Denver, CO
RE: Work flow RFC
OK. I'm running their alpha software. I'm a subscriber to the MSDN network. And I can tell you, most assuredly, that the .NET release of their products uses XSLT and XSD. I'm not kidding. Really. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Frye, Dave Sent: Tuesday, June 05, 2001 8:30 PM To: '[EMAIL PROTECTED]' Subject: RE: Work flow RFC I quote from the EAI Journal article, "Don't Discount BizTalk" from the April, 2001 issue (available online, see http://eaijournal.com/Article.asp?ArticleID=323). "... BizTalk has been criticized for not supporting the World Wide Web Consortium (W3C) standards. Rather, BizTalk is based on [older] standards." My experience with BizTalk is that the schemas we used with it were not compatible with W3C standard compliant tools. We had to modify the schemas to get them to work with BizTalk. Now, perhaps BizTalk is not up to date with Microsoft's latest efforts. It is currently using MSXML3.0, not MSXML4.0, at least in the recent version we evaluated. I really don't want to disseminate misinformation, but currently, BizTalk Server currently does not seem to be compliant. Perhaps I was being too general in my earlier statement w.r.t. Microsoft's overall XML, XSL, etc. W3C compliance. didge -Original Message- From: Dan - Blue Lotus Software [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: RE: Work flow RFC This is incorrect information. Microsoft invented schemas, and included them in their products before they were standardised. This older version of schemas is called XDR. It is what is used with the MSXML parsers from v2.0 to v3.0. The entire .NET line-up from Microsoft used the XSD specification (the W3C specification for XML schemas). The .NET line-up uses MSXML v4.0, which is completely standards compliant (this is coming from a Java programmer that uses Apache's XML tools). They are 100% compatible with the rest of the world's tools. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Frye, Dave Sent: Tuesday, June 05, 2001 7:47 PM To: '[EMAIL PROTECTED]' Subject: RE: Work flow RFC Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... didge -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Work flow RFC Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your
RE: Work flow RFC
I quote from the EAI Journal article, "Don't Discount BizTalk" from the April, 2001 issue (available online, see http://eaijournal.com/Article.asp?ArticleID=323). "... BizTalk has been criticized for not supporting the World Wide Web Consortium (W3C) standards. Rather, BizTalk is based on [older] standards." My experience with BizTalk is that the schemas we used with it were not compatible with W3C standard compliant tools. We had to modify the schemas to get them to work with BizTalk. Now, perhaps BizTalk is not up to date with Microsoft's latest efforts. It is currently using MSXML3.0, not MSXML4.0, at least in the recent version we evaluated. I really don't want to disseminate misinformation, but currently, BizTalk Server currently does not seem to be compliant. Perhaps I was being too general in my earlier statement w.r.t. Microsoft's overall XML, XSL, etc. W3C compliance. didge -Original Message- From: Dan - Blue Lotus Software [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 12:16 PM To: [EMAIL PROTECTED] Subject: RE: Work flow RFC This is incorrect information. Microsoft invented schemas, and included them in their products before they were standardised. This older version of schemas is called XDR. It is what is used with the MSXML parsers from v2.0 to v3.0. The entire .NET line-up from Microsoft used the XSD specification (the W3C specification for XML schemas). The .NET line-up uses MSXML v4.0, which is completely standards compliant (this is coming from a Java programmer that uses Apache's XML tools). They are 100% compatible with the rest of the world's tools. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Frye, Dave Sent: Tuesday, June 05, 2001 7:47 PM To: '[EMAIL PROTECTED]' Subject: RE: Work flow RFC Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... didge -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Work flow RFC Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the ele
RE: Work flow RFC
Oh, yes. XSL was invented by Microsoft, too. And included in their products before it was standardised. Their latest line of products uses a completely XSLT-compliant (that is, standard XSL) version of XSL (that's a misnomer...MS's version was XSL, the "new" version is XSLT...so saying they are XSLT-compliant is enough). -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Dan - Blue Lotus Software Sent: Tuesday, June 05, 2001 8:16 PM To: [EMAIL PROTECTED] Subject: RE: Work flow RFC This is incorrect information. Microsoft invented schemas, and included them in their products before they were standardised. This older version of schemas is called XDR. It is what is used with the MSXML parsers from v2.0 to v3.0. The entire .NET line-up from Microsoft used the XSD specification (the W3C specification for XML schemas). The .NET line-up uses MSXML v4.0, which is completely standards compliant (this is coming from a Java programmer that uses Apache's XML tools). They are 100% compatible with the rest of the world's tools. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Frye, Dave Sent: Tuesday, June 05, 2001 7:47 PM To: '[EMAIL PROTECTED]' Subject: RE: Work flow RFC Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... didge -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Work flow RFC Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of th
RE: Work flow RFC
This is incorrect information. Microsoft invented schemas, and included them in their products before they were standardised. This older version of schemas is called XDR. It is what is used with the MSXML parsers from v2.0 to v3.0. The entire .NET line-up from Microsoft used the XSD specification (the W3C specification for XML schemas). The .NET line-up uses MSXML v4.0, which is completely standards compliant (this is coming from a Java programmer that uses Apache's XML tools). They are 100% compatible with the rest of the world's tools. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Frye, Dave Sent: Tuesday, June 05, 2001 7:47 PM To: '[EMAIL PROTECTED]' Subject: RE: Work flow RFC Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... didge -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Work flow RFC Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments w
Re: Resetting a bean
The ActionServlet usually does this for you when it is needed. In general, your ActionForm beans should be in request context, and so you would start out a fresh one with a new request cycle. If validation fails, the ActionForm beans carries the data back to the input form so the user can correct it. Struts does try to recycle ActionForm beans when it can, and will calls reset() on a pre-existing bean before populating it again from the request. You generally should not need to call this yourself. It is important to remember that ActionForm beans are transitory and should only be used to ferry data between the HTML form and the Action, where the data can be transferred to a persistent object. [EMAIL PROTECTED] wrote: > > All, > > What's the best way to call the reset() method on a Form Bean? (so that all > the values on a form are always the default ones) > > Is there a tag to do so? > > Regards, > > Sean
RE: Work flow RFC
Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... didge -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 11:48 AM To: [EMAIL PROTECTED] Subject: Re: Work flow RFC Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > >
Re: Work flow RFC
> Good catch. Well, that just means that it is an issue across the board. > Lets get a list together of possible approaches and put it up somewhere for > us to comment on and review. > Like this thread :) > > - Original Message - > From: "Frye, Dave" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 2:22 PM > Subject: RE: Work flow RFC > > > >From Barracuda's Scope Summary (see, > > http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4), > > Barracuda's scope explicitly excludes application flow control. > > > > didge > > begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Re: Work flow RFC
Ahhh, thanks Dan. I didn't realize it spat out a workflow file Thanks, Craig. Dan - Blue Lotus Software wrote: > I think you misunderstood me. I'm not suggesting any SOAP interfaces or > anything. I'm simply suggesting using Visio's workflow editor to create > workflows that can be imported for Struts workflows. This should be able to > be done by simply creating 2 XSL files: one to convert Visio's workflows > into Strut's, and one to convert Strut's into Visio's. > > My primary point was to say that the next release of Visio has a workflow > editor, it outputs an XML file, and the XML format will likely be public. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 6:52 PM > To: Dan - Blue Lotus Software > Cc: [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > I don't want to be platform specific though w.r.t. any tools generated from > this TODO. However, if someone wanted to create a Visio addin for the > front-end and some SOAP interfaces to the support objects I wouldn't oppose > it. > > Craig. > > Dan - Blue Lotus Software wrote: > > > It would be nice if we could integrate directly with Visio. Microsoft is > > pushing Visio as their workflow editor for BizTalk. Basically, it allows > > Visio models to be connected to real code through the use of XML files, > > pretty much as you have suggested (except without the XSL stage--the file > > format Visio writes is read directly). > > > > At the XML One conference in London a few months back, I asked the two > > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > > the upcoming .NET version) if they planned to publish the DTD. They > didn't > > really know. However, given their commitment to open standards with XML > > (yes, I said that with a straight face), the DTD will likely be released > to > > a standards body. > > > > If this is the case, building XSL documents to handle the conversion each > > way should be straightforward. > > > > -dan > > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]. > > org]On Behalf Of Craig Tataryn > > Sent: Tuesday, June 05, 2001 5:29 PM > > To: [EMAIL PROTECTED] > > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > > begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Re: Work flow RFC
Good catch. Well, that just means that it is an issue across the board. Lets get a list together of possible approaches and put it up somewhere for us to comment on and review. - Original Message - From: "Frye, Dave" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 2:22 PM Subject: RE: Work flow RFC > >From Barracuda's Scope Summary (see, > http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4), > Barracuda's scope explicitly excludes application flow control. > > didge > > -Original Message- > From: Jonathan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 05, 2001 9:34 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Work flow RFC > > > Again, Ive got to say look at the Barracuda project. They have one of these > gui configurers. Check it out at > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > > - Original Message - > From: "Craig Tataryn" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 12:28 PM > Subject: Work flow RFC > > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > > > > >
RE: Work flow RFC
>From Barracuda's Scope Summary (see, http://barracuda.enhydra.org/Barracuda/docs/scope_summary.html#2.4), Barracuda's scope explicitly excludes application flow control. didge -Original Message- From: Jonathan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 9:34 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Work flow RFC Again, Ive got to say look at the Barracuda project. They have one of these gui configurers. Check it out at http://barracuda.enhydra.org/Barracuda/GetBConfig.event - Original Message - From: "Craig Tataryn" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 12:28 PM Subject: Work flow RFC > Hi, I would like your comments for the workflow item on our TODO list. > Currently this is how I've envisioned the workflow project: > > 1) A nice GUI type Applet or Application that has visual constructs > which can be connected in a Visio type manner to create an Activity > diagram or some other type of flow diagram. > > 2) This diagram will be persisted in an XML file which holds meta data > for the elements in diagram (position, type of construct (controller, > flat html page, cgi script, flow arrow, etc..)). > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > course some sort of "pretty layout" code would have to be used to > un-jumble the mess of constructs that are sucked out of the > struts-config.xml file (i.e. take a guess at proper positioning > information). > > The GUI should employ some sort of extensibility mechanism like BSF > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > (http://www.beanshell.org/) to allow users to plug-in their own > functionality (i.e. validation code) without jeopardizing the core code > (what I call the Emeril Lagasse technique -- BAM!). > > I realize this is a very high level look at the TODO but I think as we > get more comments we will get more granular and can start dishing out > segments. > > Let me know what you think. > > >
RE: Work flow RFC
I think you misunderstood me. I'm not suggesting any SOAP interfaces or anything. I'm simply suggesting using Visio's workflow editor to create workflows that can be imported for Struts workflows. This should be able to be done by simply creating 2 XSL files: one to convert Visio's workflows into Strut's, and one to convert Strut's into Visio's. My primary point was to say that the next release of Visio has a workflow editor, it outputs an XML file, and the XML format will likely be public. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Craig Tataryn Sent: Tuesday, June 05, 2001 6:52 PM To: Dan - Blue Lotus Software Cc: [EMAIL PROTECTED] Subject: Re: Work flow RFC I don't want to be platform specific though w.r.t. any tools generated from this TODO. However, if someone wanted to create a Visio addin for the front-end and some SOAP interfaces to the support objects I wouldn't oppose it. Craig. Dan - Blue Lotus Software wrote: > It would be nice if we could integrate directly with Visio. Microsoft is > pushing Visio as their workflow editor for BizTalk. Basically, it allows > Visio models to be connected to real code through the use of XML files, > pretty much as you have suggested (except without the XSL stage--the file > format Visio writes is read directly). > > At the XML One conference in London a few months back, I asked the two > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > the upcoming .NET version) if they planned to publish the DTD. They didn't > really know. However, given their commitment to open standards with XML > (yes, I said that with a straight face), the DTD will likely be released to > a standards body. > > If this is the case, building XSL documents to handle the conversion each > way should be straightforward. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 5:29 PM > To: [EMAIL PROTECTED] > Subject: Work flow RFC > > Hi, I would like your comments for the workflow item on our TODO list. > Currently this is how I've envisioned the workflow project: > > 1) A nice GUI type Applet or Application that has visual constructs > which can be connected in a Visio type manner to create an Activity > diagram or some other type of flow diagram. > > 2) This diagram will be persisted in an XML file which holds meta data > for the elements in diagram (position, type of construct (controller, > flat html page, cgi script, flow arrow, etc..)). > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > course some sort of "pretty layout" code would have to be used to > un-jumble the mess of constructs that are sucked out of the > struts-config.xml file (i.e. take a guess at proper positioning > information). > > The GUI should employ some sort of extensibility mechanism like BSF > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > (http://www.beanshell.org/) to allow users to plug-in their own > functionality (i.e. validation code) without jeopardizing the core code > (what I call the Emeril Lagasse technique -- BAM!). > > I realize this is a very high level look at the TODO but I think as we > get more comments we will get more granular and can start dishing out > segments. > > Let me know what you think. > >
Re: Work flow RFC
Is this a workflow editor or just a configuration editor (which would be nice for struts)? craig. Jonathan wrote: > Again, Ive got to say look at the Barracuda project. They have one of these > gui configurers. Check it out at > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > - Original Message - > From: "Craig Tataryn" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 12:28 PM > Subject: Work flow RFC > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > > > > begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Re: Work flow RFC
I don't want to be platform specific though w.r.t. any tools generated from this TODO. However, if someone wanted to create a Visio addin for the front-end and some SOAP interfaces to the support objects I wouldn't oppose it. Craig. Dan - Blue Lotus Software wrote: > It would be nice if we could integrate directly with Visio. Microsoft is > pushing Visio as their workflow editor for BizTalk. Basically, it allows > Visio models to be connected to real code through the use of XML files, > pretty much as you have suggested (except without the XSL stage--the file > format Visio writes is read directly). > > At the XML One conference in London a few months back, I asked the two > Microsoft guys that were demoing a beta of the Visio workflow stuff (from > the upcoming .NET version) if they planned to publish the DTD. They didn't > really know. However, given their commitment to open standards with XML > (yes, I said that with a straight face), the DTD will likely be released to > a standards body. > > If this is the case, building XSL documents to handle the conversion each > way should be straightforward. > > -dan > > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]. > org]On Behalf Of Craig Tataryn > Sent: Tuesday, June 05, 2001 5:29 PM > To: [EMAIL PROTECTED] > Subject: Work flow RFC > > Hi, I would like your comments for the workflow item on our TODO list. > Currently this is how I've envisioned the workflow project: > > 1) A nice GUI type Applet or Application that has visual constructs > which can be connected in a Visio type manner to create an Activity > diagram or some other type of flow diagram. > > 2) This diagram will be persisted in an XML file which holds meta data > for the elements in diagram (position, type of construct (controller, > flat html page, cgi script, flow arrow, etc..)). > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > course some sort of "pretty layout" code would have to be used to > un-jumble the mess of constructs that are sucked out of the > struts-config.xml file (i.e. take a guess at proper positioning > information). > > The GUI should employ some sort of extensibility mechanism like BSF > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > (http://www.beanshell.org/) to allow users to plug-in their own > functionality (i.e. validation code) without jeopardizing the core code > (what I call the Emeril Lagasse technique -- BAM!). > > I realize this is a very high level look at the TODO but I think as we > get more comments we will get more granular and can start dishing out > segments. > > Let me know what you think. > > begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Resetting a bean
All, What's the best way to call the reset() method on a Form Bean? (so that all the values on a form are always the default ones) Is there a tag to do so? Regards, Sean
RE: Work flow RFC
It would be nice if we could integrate directly with Visio. Microsoft is pushing Visio as their workflow editor for BizTalk. Basically, it allows Visio models to be connected to real code through the use of XML files, pretty much as you have suggested (except without the XSL stage--the file format Visio writes is read directly). At the XML One conference in London a few months back, I asked the two Microsoft guys that were demoing a beta of the Visio workflow stuff (from the upcoming .NET version) if they planned to publish the DTD. They didn't really know. However, given their commitment to open standards with XML (yes, I said that with a straight face), the DTD will likely be released to a standards body. If this is the case, building XSL documents to handle the conversion each way should be straightforward. -dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. org]On Behalf Of Craig Tataryn Sent: Tuesday, June 05, 2001 5:29 PM To: [EMAIL PROTECTED] Subject: Work flow RFC Hi, I would like your comments for the workflow item on our TODO list. Currently this is how I've envisioned the workflow project: 1) A nice GUI type Applet or Application that has visual constructs which can be connected in a Visio type manner to create an Activity diagram or some other type of flow diagram. 2) This diagram will be persisted in an XML file which holds meta data for the elements in diagram (position, type of construct (controller, flat html page, cgi script, flow arrow, etc..)). 3) The diagram can be exported to a struts config file via XSLT (i.e. workflow.xml -> workflow2struts.xsl -> struts-config.xml) 4) A diagram can also be imported from a struts-config.xml file via XSLT (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of course some sort of "pretty layout" code would have to be used to un-jumble the mess of constructs that are sucked out of the struts-config.xml file (i.e. take a guess at proper positioning information). The GUI should employ some sort of extensibility mechanism like BSF (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell (http://www.beanshell.org/) to allow users to plug-in their own functionality (i.e. validation code) without jeopardizing the core code (what I call the Emeril Lagasse technique -- BAM!). I realize this is a very high level look at the TODO but I think as we get more comments we will get more granular and can start dishing out segments. Let me know what you think.
Re: Work flow RFC
The lead on the Barracuda project is a subscriber to the Struts list! Christian Cryder ([EMAIL PROTECTED]) He was the one who said he likes to "lurk" and spoke about security on Monday May 7, "RE: Potential Security Flaw in Struts MVC" - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 12:48 PM Subject: Re: Work flow RFC > I'm still fuzzy on the mechanism we would use to represent and enforce > the workflow. There has been mention of things like command tokens, but > are any code samples available. > > Can anyone explain how Barracuda implements their workflow, and whether > it could be mapped to the Struts Actions/ActionMappings model? > > I believe Barracuda and Struts are complementary in most ways, and it > would be in our best interest to adopt and adapt rather than > roll-our-own, if feasible. > > Jonathan wrote: > > > > Again, Ive got to say look at the Barracuda project. They have one of these > > gui configurers. Check it out at > > http://barracuda.enhydra.org/Barracuda/GetBConfig.event >
Re: Work flow RFC
Thanks Jonathan, I haven't been monitoring the list for a while so this is news to me! Keep 'em coming! Craig T. Jonathan wrote: > Again, Ive got to say look at the Barracuda project. They have one of these > gui configurers. Check it out at > http://barracuda.enhydra.org/Barracuda/GetBConfig.event > > - Original Message - > From: "Craig Tataryn" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 12:28 PM > Subject: Work flow RFC > > > Hi, I would like your comments for the workflow item on our TODO list. > > Currently this is how I've envisioned the workflow project: > > > > 1) A nice GUI type Applet or Application that has visual constructs > > which can be connected in a Visio type manner to create an Activity > > diagram or some other type of flow diagram. > > > > 2) This diagram will be persisted in an XML file which holds meta data > > for the elements in diagram (position, type of construct (controller, > > flat html page, cgi script, flow arrow, etc..)). > > > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > > course some sort of "pretty layout" code would have to be used to > > un-jumble the mess of constructs that are sucked out of the > > struts-config.xml file (i.e. take a guess at proper positioning > > information). > > > > The GUI should employ some sort of extensibility mechanism like BSF > > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > > (http://www.beanshell.org/) to allow users to plug-in their own > > functionality (i.e. validation code) without jeopardizing the core code > > (what I call the Emeril Lagasse technique -- BAM!). > > > > I realize this is a very high level look at the TODO but I think as we > > get more comments we will get more granular and can start dishing out > > segments. > > > > Let me know what you think. > > > > > > begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Re: Work flow RFC
I'm still fuzzy on the mechanism we would use to represent and enforce the workflow. There has been mention of things like command tokens, but are any code samples available. Can anyone explain how Barracuda implements their workflow, and whether it could be mapped to the Struts Actions/ActionMappings model? I believe Barracuda and Struts are complementary in most ways, and it would be in our best interest to adopt and adapt rather than roll-our-own, if feasible. Jonathan wrote: > > Again, Ive got to say look at the Barracuda project. They have one of these > gui configurers. Check it out at > http://barracuda.enhydra.org/Barracuda/GetBConfig.event
Re: Client/Server Side Validation for Struts 1.1
I still think it may be better to have one validation package and a bunch of filter/transformers for each lnaguage and local you want to support. That way the user can enter in data in the way he/she is accostomed, and we developers who are aware of such differences can convert the users format into our own which we use to process and validate. When you want to add a language and or local, just make a filter/converter for it, and use the exact same validation package without having to add to it for each local/language. Would love to hear any comment on this. cheers Jonathan - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 10:55 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > > Memo from Nic Hobbs of PricewaterhouseCoopers > > Start of message text > > Firstly let me apologise for my lack of communication recently - we have > had some deadlines on our project that have kept me busy. I have been > lurking and listening to the discussions though, but find I often am too > late to reply to things - when I get around to it someone has already > answered the question! Especially with most of you being in a different > time zone ;) > > Anyway, on to the point. I agree that we need to distinguish between the > view and the model here. It has long been a concern of mine, coming from a > languages and linguistics background originally that, especially in the > java world, locales are too simplified for many of the reasons that have > been mooted here. > > However, I don't think we need to complicate things too much. William is > right by saying that, in the example of currencies, the calcualation of the > value in different currencies is the responsilibity of the business logic, > whether by a feed or a static table or however. The responsibility of the > view is just to render it with the correct currency format. > > This however, doesn't answer the questions of our now well mooted Spanish > speaking, mexican ex-pat, californian trying to buy in Brazil (phew...). I > would like to point something out on this score though. The chances are > that if our mexican friend is accessing a brazilian website the values they > will be seeing will be in the currency of that country rather than in their > own. So several things: a) we cannot just use their local to render the > values as this will list them in US dollars and b) for most sites the > closest they get to showing currency conversions is a link to an external > site that does this sort of thing, so we don't have to worry about > conversion c) we can only really validate an address against a PAF (an > address/postcode file in the UK) or its equivalent. > > This leaves us with an interesting scenario. We have found that the locale > needed to render the values is in fact that of the server rather than the > client (which is not the current struts approach) and that in order for the > customer to complete their order they will need to enter in an address > which is in their locale and not the server's (ie potentially different > postcodes (sorry I'm european!) and 'phone numbers). > > So how do we handle this? The display of values that we have control over > is pretty straight forward as we can control the server locales ourselves > and render them on the screen accordingly, although not using the automatic > recognition of locale that struts supports. This is also true of multiple > currencies such as the example of euros and DM in Germany. This is in fact > something we are dealing with on our project for a financial client at the > moment. > > The others are more of a problem. However, again there are several > strategies that we can adopt as far as I see it. The first is that in the > scenario above there may well be a limit to where the company is prepared > to export to and therefore they only need to support the locales they want > to. The second is that we could support minor validation on the client side > (ie a phone number is only numbers and brackets or something similar) and > do the full validation on the server side based on subclasses for each > locale we want to support. In this scenario we have one form for all > locales (used loosely) but check the format on the server for a specific > locale. However, we still have problems even here. Take for instance the > Spanish name. US and UK names tend to be along the lines of Fred Smith. > Spanish names include both the mother's and father's surnames i.e. Fred > Jones Smith (well the spanish equivalent anyway ;) How can we cope with > this on one form? Aren't these business decisions to be made rather than > one's for the framework? > > I think we need to concentrate IMHO on several things - the first is that > we are trying to provide a framework for people to do their validations in > easily rather than to provide an application that validates every > conceivable option. The second
Re: Client/Server Side Validation for Struts 1.1
I still have the feeling that we lack a decent foundation package to do the grunt work of typecasting and String formatting, so that things like a Validation servlet and something like a tag could share a common codebase. We might want to start with something like this: < http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01522.html > Perhaps as an extension to java.text.Format, as Rey Francois has been suggesting: < http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02711.html > And then look at how we can use this package to extend the Validation servlet and enhance the bean tags. It's a little confusing now, since validations, conversions, and transformations and are closely linked, but appear at different points in the input / store / output continuum. Even so, I think the processes have enough in common to create a cohesive package, even if you would not use every method on any one layer of a MVC application. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: Client/Server Side Validation for Struts 1.1
Another thing to consider along these lines is just going full-force with typing. I've done this in the past for measurement systems and it worked out very well. Rather than having a bunch of BigDecimals hanging around with values of different "types", you could create specific subclasses for the various monetary types you want to support. It's a little painful but it's really the only way the business layer and presentation layer can avoid the confusion that's bound to arise. So if an object is a Euro you display it as such, if it's a Dollar you display it as dollars, etc.. That way you don't end up accidentally displaying a dollar amount as pounds since the presentation layer can be smart enough to format the type appropriately. -Paul Speed William Jaynes wrote: > > Remember... separation of view from model. The act of displaying an > amount in a particular currency format is separate from determining what > that amount is. So the code used to implement the display of the amount > should not be mixed up with the code used to determine the amount. > > - Original Message - > From: "Jonathan Asbell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 7:40 AM > Subject: Re: Client/Server Side Validation for Struts 1.1 > > > Ok, so why then is this an issue. What is the value of seeing Pounds > AND > > Euros on the same page if you dont want to realte their rates. Ok, so > I > > could enter data using pounds, or enter data using Euros depending on > my > > personalization setting. But what is the use of DISPLAYING both if > you wont > > give me then conversion? > > > > By the way Ted, you are up early man. I guess it finally thawed out > upstate > > ;^> > > > > - Original Message - > > From: "Ted Husted" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, June 05, 2001 7:28 AM > > Subject: Re: Client/Server Side Validation for Struts 1.1 > > > > > > > Wouldn't exchange rates count as business logic? > > > > > > I think the thrust here is the ability to take a given binary number > and > > > display it using the currency sign and format ($###.## vs ###,##DM] > for > > > a given nation. This package would consider the value immutable. > Another > > > player would have to change the binary value first, and then pass it > > > along for formatting. > > > > > > Jonathan Asbell wrote: > > > > > > > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda" > > > > > > > > What about allowing two or three different displays of currency, > but > > only > > > > one type of currency for data entry. That way I could be in > England > > > > entering pounds, but seeing display values in Pounds, Hong Kong $, > and > > Euro. > > > > Of course this keeps making me think that at this point we are > talking > > about > > > > accessing the current exchange rates, which than you would need a > feed > > etc. > > > > This IS true because thereare countries in SOuth america whos > currency > > jumps > > > > and dives each week, and you would not be presenting viewers with > the > > > > correct exchange. > > > > >
Re: Work flow RFC
Again, Ive got to say look at the Barracuda project. They have one of these gui configurers. Check it out at http://barracuda.enhydra.org/Barracuda/GetBConfig.event - Original Message - From: "Craig Tataryn" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 12:28 PM Subject: Work flow RFC > Hi, I would like your comments for the workflow item on our TODO list. > Currently this is how I've envisioned the workflow project: > > 1) A nice GUI type Applet or Application that has visual constructs > which can be connected in a Visio type manner to create an Activity > diagram or some other type of flow diagram. > > 2) This diagram will be persisted in an XML file which holds meta data > for the elements in diagram (position, type of construct (controller, > flat html page, cgi script, flow arrow, etc..)). > > 3) The diagram can be exported to a struts config file via XSLT (i.e. > workflow.xml -> workflow2struts.xsl -> struts-config.xml) > > 4) A diagram can also be imported from a struts-config.xml file via XSLT > (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of > course some sort of "pretty layout" code would have to be used to > un-jumble the mess of constructs that are sucked out of the > struts-config.xml file (i.e. take a guess at proper positioning > information). > > The GUI should employ some sort of extensibility mechanism like BSF > (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell > (http://www.beanshell.org/) to allow users to plug-in their own > functionality (i.e. validation code) without jeopardizing the core code > (what I call the Emeril Lagasse technique -- BAM!). > > I realize this is a very high level look at the TODO but I think as we > get more comments we will get more granular and can start dishing out > segments. > > Let me know what you think. > > >
Work flow RFC
Hi, I would like your comments for the workflow item on our TODO list. Currently this is how I've envisioned the workflow project: 1) A nice GUI type Applet or Application that has visual constructs which can be connected in a Visio type manner to create an Activity diagram or some other type of flow diagram. 2) This diagram will be persisted in an XML file which holds meta data for the elements in diagram (position, type of construct (controller, flat html page, cgi script, flow arrow, etc..)). 3) The diagram can be exported to a struts config file via XSLT (i.e. workflow.xml -> workflow2struts.xsl -> struts-config.xml) 4) A diagram can also be imported from a struts-config.xml file via XSLT (i.e. struts-config.xml -> struts2workflow.xsl -> workflow.xml). Of course some sort of "pretty layout" code would have to be used to un-jumble the mess of constructs that are sucked out of the struts-config.xml file (i.e. take a guess at proper positioning information). The GUI should employ some sort of extensibility mechanism like BSF (http://oss.software.ibm.com/developerworks/projects/bsf) or Bean Shell (http://www.beanshell.org/) to allow users to plug-in their own functionality (i.e. validation code) without jeopardizing the core code (what I call the Emeril Lagasse technique -- BAM!). I realize this is a very high level look at the TODO but I think as we get more comments we will get more granular and can start dishing out segments. Let me know what you think. begin:vcard n:Tataryn;Craig x-mozilla-html:TRUE url:http://www.computer-programmer.org org:Compuware;Professional Services Division adr:;;;Bloomington;MN;55431;United States of America version:2.1 email;internet:[EMAIL PROTECTED] title:http://www-server/~xxtatar/images/mcp_sd_sml.gif";>Programmer/Analyst fn:Craig Tataryn end:vcard
Re: Client/Server Side Validation for Struts 1.1
I agree with Nick that a lot of these scenarios can't be known until the user enters the country that the address info belongs to. What if someone in Britain is sending a gift to someone in France? What if your home address is in one country and you work in another so you put down your business phone for contact info and it won't let you? I don't like forms that reject what I'm entering. I think in the US you can probably be specific, but in Europe I always thought it would be easier to have vary loose validation rather than trying to figure out all of the possible combinations of a user's locale, the country they entered, etc. This is an excerpt from an earlier e-mail. Ted Husted wrote: and so forth. We could put these in seperate files, or just make them sections of the validation.xml. tel = ## ## This would be very easy to do. Maybe when we make formatting tags they could access this info and then you could specify whether or not to use the server's default locale (ex: currency display), the client's locale, or pass in your own format. Nothing for the locale could default to either server or client. We could decide what makes the most sense or it could be configurable when you setup the default formats. 5135551212 I think that it might be good to stick to upper case representations of countries like the java.util.Locale object returns when you call getCountry(). 5135551212 5135551212 David --- [EMAIL PROTECTED] wrote: > > Memo from Nic Hobbs of PricewaterhouseCoopers > > Start of message text > > > Firstly let me apologise for my lack of > communication recently - we have > had some deadlines on our project that have kept me > busy. I have been > lurking and listening to the discussions though, but > find I often am too > late to reply to things - when I get around to it > someone has already > answered the question! Especially with most of you > being in a different > time zone ;) > > Anyway, on to the point. I agree that we need to > distinguish between the > view and the model here. It has long been a concern > of mine, coming from a > languages and linguistics background originally > that, especially in the > java world, locales are too simplified for many of > the reasons that have > been mooted here. > > However, I don't think we need to complicate things > too much. William is > right by saying that, in the example of currencies, > the calcualation of the > value in different currencies is the responsilibity > of the business logic, > whether by a feed or a static table or however. The > responsibility of the > view is just to render it with the correct currency > format. > > This however, doesn't answer the questions of our > now well mooted Spanish > speaking, mexican ex-pat, californian trying to buy > in Brazil (phew...). I > would like to point something out on this score > though. The chances are > that if our mexican friend is accessing a brazilian > website the values they > will be seeing will be in the currency of that > country rather than in their > own. So several things: a) we cannot just use their > local to render the > values as this will list them in US dollars and b) > for most sites the > closest they get to showing currency conversions is > a link to an external > site that does this sort of thing, so we don't have > to worry about > conversion c) we can only really validate an address > against a PAF (an > address/postcode file in the UK) or its equivalent. > > This leaves us with an interesting scenario. We have > found that the locale > needed to render the values is in fact that of the > server rather than the > client (which is not the current struts approach) > and that in order for the > customer to complete their order they will need to > enter in an address > which is in their locale and not the server's (ie > potentially different > postcodes (sorry I'm european!) and 'phone numbers). > > So how do we handle this? The display of values that > we have control over > is pretty straight forward as we can control the > server locales ourselves > and render them on the screen accordingly, although > not using the automatic > recognition of locale that struts supports. This is > also true of multiple > currencies such as the example of euros and DM in > Germany. This is in fact > something we are dealing with on our project for a > financial client at the > moment. > > The others are more of a problem. However, again > there are several > strategies that we can adopt as far as I see it. The > first is that in the > scenario above there may well be a limit to where > the company is prepared > to export to and therefore they only need to support > the locales they want > to. The second is that we could support minor > validation on the client side > (ie a phone number is only numbers and brackets or > something similar) and > do the full validation on the server side based on > s
Re: Client/Server Side Validation for Struts 1.1
Memo from Nic Hobbs of PricewaterhouseCoopers Start of message text Firstly let me apologise for my lack of communication recently - we have had some deadlines on our project that have kept me busy. I have been lurking and listening to the discussions though, but find I often am too late to reply to things - when I get around to it someone has already answered the question! Especially with most of you being in a different time zone ;) Anyway, on to the point. I agree that we need to distinguish between the view and the model here. It has long been a concern of mine, coming from a languages and linguistics background originally that, especially in the java world, locales are too simplified for many of the reasons that have been mooted here. However, I don't think we need to complicate things too much. William is right by saying that, in the example of currencies, the calcualation of the value in different currencies is the responsilibity of the business logic, whether by a feed or a static table or however. The responsibility of the view is just to render it with the correct currency format. This however, doesn't answer the questions of our now well mooted Spanish speaking, mexican ex-pat, californian trying to buy in Brazil (phew...). I would like to point something out on this score though. The chances are that if our mexican friend is accessing a brazilian website the values they will be seeing will be in the currency of that country rather than in their own. So several things: a) we cannot just use their local to render the values as this will list them in US dollars and b) for most sites the closest they get to showing currency conversions is a link to an external site that does this sort of thing, so we don't have to worry about conversion c) we can only really validate an address against a PAF (an address/postcode file in the UK) or its equivalent. This leaves us with an interesting scenario. We have found that the locale needed to render the values is in fact that of the server rather than the client (which is not the current struts approach) and that in order for the customer to complete their order they will need to enter in an address which is in their locale and not the server's (ie potentially different postcodes (sorry I'm european!) and 'phone numbers). So how do we handle this? The display of values that we have control over is pretty straight forward as we can control the server locales ourselves and render them on the screen accordingly, although not using the automatic recognition of locale that struts supports. This is also true of multiple currencies such as the example of euros and DM in Germany. This is in fact something we are dealing with on our project for a financial client at the moment. The others are more of a problem. However, again there are several strategies that we can adopt as far as I see it. The first is that in the scenario above there may well be a limit to where the company is prepared to export to and therefore they only need to support the locales they want to. The second is that we could support minor validation on the client side (ie a phone number is only numbers and brackets or something similar) and do the full validation on the server side based on subclasses for each locale we want to support. In this scenario we have one form for all locales (used loosely) but check the format on the server for a specific locale. However, we still have problems even here. Take for instance the Spanish name. US and UK names tend to be along the lines of Fred Smith. Spanish names include both the mother's and father's surnames i.e. Fred Jones Smith (well the spanish equivalent anyway ;) How can we cope with this on one form? Aren't these business decisions to be made rather than one's for the framework? I think we need to concentrate IMHO on several things - the first is that we are trying to provide a framework for people to do their validations in easily rather than to provide an application that validates every conceivable option. The second is that not all validations can be represented in regular expressions ( this is not to take anything from david's validation framework, which although I have not used myself looks good as a basis, as Ted suggested). The third is that we should provide for 'cross-field' validations - if the user selects this option they should only fill in these fields etc. And the fourth, the big one is, i18n. So where do I suggest we go from here? Well that is a good question. Part of me thinks we should concentrate on 1-3 above to provide a framework for people to use for validation however they want to; Part of me knows, from experience, you can't bolt on i18n after the fact. So what I can suggest so far is to concentrate on getting a framework together which doesn't preclude us from doing anything fancy with i18n but that doesn't have it as it's only initial goal. To a certain extent, and I k
Re: Client/Server Side Validation for Struts 1.1
Remember... separation of view from model. The act of displaying an amount in a particular currency format is separate from determining what that amount is. So the code used to implement the display of the amount should not be mixed up with the code used to determine the amount. - Original Message - From: "Jonathan Asbell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 7:40 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > Ok, so why then is this an issue. What is the value of seeing Pounds AND > Euros on the same page if you dont want to realte their rates. Ok, so I > could enter data using pounds, or enter data using Euros depending on my > personalization setting. But what is the use of DISPLAYING both if you wont > give me then conversion? > > By the way Ted, you are up early man. I guess it finally thawed out upstate > ;^> > > - Original Message - > From: "Ted Husted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 05, 2001 7:28 AM > Subject: Re: Client/Server Side Validation for Struts 1.1 > > > > Wouldn't exchange rates count as business logic? > > > > I think the thrust here is the ability to take a given binary number and > > display it using the currency sign and format ($###.## vs ###,##DM] for > > a given nation. This package would consider the value immutable. Another > > player would have to change the binary value first, and then pass it > > along for formatting. > > > > Jonathan Asbell wrote: > > > > > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda" > > > > > > What about allowing two or three different displays of currency, but > only > > > one type of currency for data entry. That way I could be in England > > > entering pounds, but seeing display values in Pounds, Hong Kong $, and > Euro. > > > Of course this keeps making me think that at this point we are talking > about > > > accessing the current exchange rates, which than you would need a feed > etc. > > > This IS true because thereare countries in SOuth america whos currency > jumps > > > and dives each week, and you would not be presenting viewers with the > > > correct exchange. > > >
Custom data source properties
Hi all, Im using JDataConnect with struts, all working fine except there are some 'custom' properties that the driver supports that I want to set. In this instance Unicode support, but it could be anything. Ive mod'd the necessary code for 'data-source' to reference an 'extPropsFile' attribute (eg extPropsFile=myCustomDriver.properties) and load it from the root of the webapp classes root, adding properties found therein to the properties list built from the other data-source attributes and passed onto the driver. My main reason for going to an external properties file is that there are always custom properties that are peculiar to drivers, polluting the data-source attributes to support them all is in my view not the way to go. I can appreciate trying to keep the data-source attribute list as concrete as possible is a good thing, but still. Any comments on this approach? If its seen to be useful Ill happily post the changes, its not much code. TTFN andy. [EMAIL PROTECTED] import com.mh.theViewsExpressedHereinAreMyOwnNotThatOfMyCompany;
Re: question about Action Forwards in struts-config
The idea of begin able to script a workflow in struts-config has been kicked around a bit, but I don't think anyone has brought any code to the table. Personally, I'm starting to play around with the idea of a stack that would push URIs that were part of a workflow, and the concept of "done" actions that would pop the URIs before returning to a default "done" (like say a menu). If the stack was empty, it would return null, and the default forwarding would fall through somehow. I've done this to a limited extent by setting and checking a single session attribute at specific places, and it worked rather well. A companion piece to this I'm considering is a key tracking object that I could use to fill-in the foreign keys on input forms. (I have some complex forms with several foreign keys.) The idea being I would put an input form into the session until it was inserted. Other input and selection actions could then report their lastest key accessed to the tracking object, who would update any related input form stored in the users session. (Like a controller.) This way you could wander around looking up this and that, and when you got back to your half-finished input form, the related keys would be filled in with whatever your lastest visits. (I'm not explaining this very well; code to follow if I do it.) > Jonathan Asbell wrote: > > I have boiled down action forward to a few exact situations. I would > only want to do any of the following situations: > 1) take me back where I was > 2) take me back to where I was trying to go > 3) take me to a specific page > 4) take me to a default page > > I dont believe there is currently a neat and clean way of describing > this in the struts-config. Maybe there doesnt need to be for things > like "where I was trying to go" and "where I was". I am just looking > for some clarity on the issues and what/why the implementation is what > it is currently is
Re: Client/Server Side Validation for Struts 1.1
Ok, so why then is this an issue. What is the value of seeing Pounds AND Euros on the same page if you dont want to realte their rates. Ok, so I could enter data using pounds, or enter data using Euros depending on my personalization setting. But what is the use of DISPLAYING both if you wont give me then conversion? By the way Ted, you are up early man. I guess it finally thawed out upstate ;^> - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 05, 2001 7:28 AM Subject: Re: Client/Server Side Validation for Struts 1.1 > Wouldn't exchange rates count as business logic? > > I think the thrust here is the ability to take a given binary number and > display it using the currency sign and format ($###.## vs ###,##DM] for > a given nation. This package would consider the value immutable. Another > player would have to change the binary value first, and then pass it > along for formatting. > > Jonathan Asbell wrote: > > > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda" > > > > What about allowing two or three different displays of currency, but only > > one type of currency for data entry. That way I could be in England > > entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro. > > Of course this keeps making me think that at this point we are talking about > > accessing the current exchange rates, which than you would need a feed etc. > > This IS true because thereare countries in SOuth america whos currency jumps > > and dives each week, and you would not be presenting viewers with the > > correct exchange. >
Re: Client/Server Side Validation for Struts 1.1
Wouldn't exchange rates count as business logic? I think the thrust here is the ability to take a given binary number and display it using the currency sign and format ($###.## vs ###,##DM] for a given nation. This package would consider the value immutable. Another player would have to change the binary value first, and then pass it along for formatting. Jonathan Asbell wrote: > > "Tonarino kyacua, yoku-ki-ka-ku Kyuacuda" > > What about allowing two or three different displays of currency, but only > one type of currency for data entry. That way I could be in England > entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro. > Of course this keeps making me think that at this point we are talking about > accessing the current exchange rates, which than you would need a feed etc. > This IS true because thereare countries in SOuth america whos currency jumps > and dives each week, and you would not be presenting viewers with the > correct exchange.
question about Action Forwards in struts-config
I have boiled down action forward to a few exact situations. I would only want to do any of the following situations: 1) take me back where I was 2) take me back to where I was trying to go 3) take me to a specific page 4) take me to a default page I dont believe there is currently a neat and clean way of describing this in the struts-config. Maybe there doesnt need to be for things like "where I was trying to go" and "where I was". I am just looking for some clarity on the issues and what/why the implementation is what it is currently is
excellent links to internationalization issues
Links to developing internationalized websites Cheers yarranet.net.au - papers on multilingual web publishing.url cs.uu Programming for Internationalization FAQ.url developerWorks - Harnessing internationalization.url IBM International Text in JDK 1.2.url IBM java classes for Unicode.url Java Byte Encodings and Strings.url Javaworld - Internationalize JSP-based Websites.url Maribyrnong - multilingual ibrary Services.url Open Road - multilingual resource site.url w3c & alis study on internationalization - August 1999.url Yamada - Font Archive.url yarranet.net.au - Making a multilingual web site.url acoin i18n Internationalization Mailing List.url
Re: Client/Server Side Validation for Struts 1.1
"Tonarino kyacua, yoku-ki-ka-ku Kyuacuda"
What about allowing two or three different displays of currency, but only
one type of currency for data entry. That way I could be in England
entering pounds, but seeing display values in Pounds, Hong Kong $, and Euro.
Of course this keeps making me think that at this point we are talking about
accessing the current exchange rates, which than you would need a feed etc.
This IS true because thereare countries in SOuth america whos currency jumps
and dives each week, and you would not be presenting viewers with the
correct exchange.
- Original Message -
From: "Michael Westbay" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 04, 2001 7:33 PM
Subject: Re: Client/Server Side Validation for Struts 1.1
> Husted-san wrote:
>
> > In this context, we would want the validators to be able to recognize
> > _xx as the location (or have a super method that parsed that from the
> > locale for them). This would allow us to continue to use the one session
> > locale property to cover both situations.
>
> But what kind of compexity are you looking at? Let's take a small example
of
> languages and countries to cover:
>
> Languages: English, Spainish, Japanese
> Locales: U.S., England, Spain, Japan
>
> Now you need resources:
>
> en, en_US, en_UK, en_ES, en_JP
> es, es_US, es_UK, es_ES, es_JP
> ja, ja_US, ja_UK, ja_ES, ja_JP
>
> Add a language, multiply by 5.
> Add a country, multipy the result by 4.
>
> And most of the strings will be repeated over and over ad. nasuim.
>
> It seems to me that the target locale (meaning place) should be separate
with
> some sort of formatted strings like "(###)###-".
>
> Units of measure (dollars, yet, pesos) etc. can be localized in the
language
> file, as well as display order. For example:
>
> Language_en.properties:
> usdollar_value=US$ {0}
> yen_value={0} yen
> peso_value={0} pesos
>
> Language_ja.properties:
> usdollar_value={0}$B%I%k(B
> yen_value={0}$B1_(B
> peso_value={0}$B%Z%=(B
>
> This way, the formatting/format checking "0.00" or "#.##" can be written
> once, and used by all of the languagues.
>
> This still doesn't cover the problem with providing a choice of two
> currencies (as in the EC). Any suggestions?
>
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home: http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/
>
RE: Client/Server Side Validation for Struts 1.1
We are developing here such validation framework. I've already posted a message about this on 11 May, but I didn't get much reply yet. The problem we are trying to solve here is to not only do a validation, but also convert the form fields into objects, e.g. from a string to a date object, an operation which is in itself a form of validation (if the conversion fails, the input is invalid). The other interesting feature of what we're developing is that once a field has been validated/converted, it can be copied onto another object property so that at the end of the validation cycle, we can directly retrieve a usable model object already populated. In our case, those objects are command objects we send to an EJB backend. We call this extension the "Mapper", as the overall concept is to map properties from one object (ActionForm) to another object (command bean, PreparedStatement, etc.), while performing validation and type conversion. The mapper is configured through an XML file with contains the mapper definitions, along with the definition of other object such as validator and converter classes. This XML configuration file is digested by the digester and results in a hierarchy of objects. At the top, the Mappers class contains the list of Validators, Converters, and Mapper instances. The Mapper class encapsulate Mappings and MappedObjects, each Mapping being a relationship between one or more MappedObjects and containing the name of the fields to "import/export". Each individual Mapping can use its own Converter. If there is a conversion problem, the Mapper calls the ConvertExceptionHandler which has been provided during its initialization. Each Mapping can also validate the input before conversion by using Validator classes. The definition of the validation is done using a small language (parsed by JJTree/JavaCC) so that multiple Validator can be combined (and, or, xor, etc.). Other interesting things to mention: each MappedObject can define its own Getter, Setter, and Creator classes, allowing us to not only support JavaBeans, but also query strings, query and result buffers, etc. Validator and Converter classes are given a Locale instance in order to support some internationalization. A Mapping can itself contain a nested Mapper, so that hierarchies of objects can also be validated/converted/mapped. Finally, the whole cycle of validating/converting/mapping can be done in one call, or can be split up into individual steps: 1. Validation, 2. Conversion, 3. Mapping, thus avoiding unnecessary processing if for example the validation fails. This mapper functionality will be used at different stages: during the validation of a form (ActionForm.validate()), during the parsing/handling of backend result messages, and whenever we need to transfer data from one object to another. In the case of form validation, we subclass the ActionForm and implemented the validate logic (look for a mapper named formName+"Mapper", call its validation, create ActionErrors in case of errors). In the future I would expect to implement two things: the recycling of the state objects (Mapper classes are stateless, state is stored in separate classes), and the inclusion of client-side validation with JavaScript, in the same way as in Dave's framework. All this is work in progress, a large part is implemented and tested. The bit I'm implementing now is the validation with Validator classes. To give you a more concrete idea of this extension, I included the DTD of the config file and a sample config file I use for my testing. Feel free to comment on this approach. I think combining validation/conversion/mapping really makes sense otherwise you'll end up writing custom code to do any of these three things. If the interest is strong enough, and if the approach gets some support, I wouldn't mind having it included in Struts at all. François Rey Financial WebSuite Capco http://www.capco.com/ -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 02 June 2001 08:43 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Client/Server Side Validation for Struts 1.1 I'd like to get a discussion started on the client/standard validations for Struts 1.1. I thought it would be good to talk about what basic features it would include and implementation. Here are the descriptions from the To Do list for 1.1. Standard Validations. Add the ability to configure standard validations on particular properties to be enforced by the controller servlet automatically. Where feasible, client-side JavaScript validations may also be generated based on the same configuration rules. Client Side Validation. Add the ability to automatically generate optional JavaScript code to perform client-side validations for things like required fields, numeric fields, dates/times/timestamps, and so on. The required validation should mesh with validation enhancements provided in the controller servlet itself. Nic Hobbs and I have both vol
Re: Proposed feature: Bean property transformations
PropertyEditors only do that as a side-effect. They are designed
to take the value out of the bean, hold it, allow modifications to
the value, and then allow the application to put it back when editing
has finished. There is a lot of overhead involved in that if all you
want is text conversion. Besides, property editors don't have to
implement the string-based methods... in which case they won't even
do the conversion for you.
-Paul Speed
William Shulman wrote:
>
> If the Transformation interface translates objects to and from
> Strings, how is it different than PropertyEditors?
>
> -will
>
> Ron Smith writes:
> > I like the idea of combining transformations with some validation
> > logic. After all, you commonly validate the contents of a String by
> > trying to transform it into some other data type.
> > I'm also interested in the discussions going on about client side
> > validation and locale/language specific validation/presentation
> > although I haven't looked at it that closely.
> >
> > Like you, this is something I could use right away, so I'm probably
> > going to work on putting something basic together pretty soon.
> >
> > I was thinking of having a Transformation interface that supported
> > transforming an object from its primary form to a secondary form -
> > for instance transforming a Date object into a String. This would
> > be a forward transformation. The Transformation interface would also
> > support transforming an object from its secondary form to its primary
> > form (e.g. String to Date) - a reverse transformation.
> > Although validation would be implicitly
> > done as a part of transformation, there'd be a seperate validate(Object) function
> > that could be called to just validate an object in its secondary form (e.g.
> > a String that holds a date representation).
> > I'd have various types of transformation classes to support the different
> > data types in the application. Some would be fairly generic and reusable
> > and some would be pretty application specific.
> >
> > I'd probably have the ActionForm have two sets of attributes for its
> > fields - the fields in String form as they came in the HTTP request, and
> > the fields in their primary data type form. This is because I usually don't
> > have a simple mapping between a form's fields and the attributes of a
> > business entity bean, so It doesn't help me to try to transform into
> > another bean's fields, might as well keep it all in the same ActionForm
> > object.
> > It'd be nice to have something automatically apply the correct
> > transformations to each field in the ActionForm and generate error
> > messages for any transformations/validations that failed.
> >
> > I'd also like to have something generic enough that it could be used
> > in non-servlet type of applications as well.
> >
> >
> > Ted Husted wrote:
> >
> > > What I'm missing is a comprehensive, general package for converting data
> > > types and formatting properties for presentation. Most of this
> > > functionality is available somewhere in java and javax space, but it's
> > > spread around.
> > >
> > > What would be most useful, I think, is a single, generic package that
> > > provided
> > >
> > > (1) validation of Strings using regular expressions (a la David
> > > Winterfeldt's servlet), with direct support for native and JDBC
> > > datatypes,
> > >
> > > (2) binary to String and String to binary conversions for all native and
> > > standard types, and support for adding others,
> > >
> > > (3) given a formatting specification ("00#.##") and data of any
> > > supported type, return a formatted presentation String,
> > >
> > > (4) support for locale-senstive transformations with (3),
> > >
> > > (5) support for extending the formatting specification for unusual
> > > circumstances, and
> > >
> > > (6) provide simple date-calculation methods and a countdown presentation
> > > format (seconds, minutes, hours, or days from now until then).
> > >
> > > We could then use this helper object during the validation cycle to
> > > convert incoming Strings to the other types needed by business-logic
> > > objects, AND pass through the functionality from a > > > tag, that could pull a property from a given bean, transform it, and return a
>formatted String for direct use by the view.
> > >
> > > If there is not something like this already out there, I've very
> > > interested in getting started on this package, since I really, really
> > > need it for my own projects. Could be a nice addition to the Commons ...
> > >
> > > I'm cross-posting this to Struts user in case someone can suggest a
> > > package that already provides this functionality.
> > >
> > > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > > -- Custom Software ~ Technical Services.
> > > -- Tel 716 737-3463.
> > > -- http://www.husted.com/about/struts/
> > >
> > > Ron Smith wrote:
> > >
