adding dds to existing webfacing project

[Guest.Visitor]

Hi Lluís, I think that if you are unsure then the best thing would be to simply re-export the entire thing. Parts of the webapp that will be changed by adding a new DDS member would be the record JSP's (new jsp's added) and record beans (new beans added). Also if you have added a new CL command definition there would also be a new invocation added. The simplest, best and most sure thing would be to re-export it all... Kind regards, Mike Lluís Segura wrote: > Hello all, > > When i add a new DDS to an existing webfacing project, convert this DDS >and, what parts of this project have i to export? > > Thanks in advance > > Lluís > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com

[David Abramowitz]

Mike Hockings wrote: The simplest, best and most sure thing would be to re-export it all... That seems very cumbersome. Is there something in the works to simplify matters? Dave

[Guest.Visitor]

Hi Dave, What are you thinking of? That is, what do you think would simplify it for you? To me exporting the whole thing is the easiest, when I'm working on a particular project it's just File->Export, click, click, click and it's done. Copying individual parts means finding both the source and the destination files in the file system and moving the right ones to the right places. Seems messy & very prone to error, IMHO. Kind regards, Mike David Abramowitz wrote: >Mike Hockings wrote: The simplest, >best and most sure thing would be to re-export it all... > >That seems very cumbersome. Is there something in the works to simplify matters? > >Dave > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com

[J.Pluta]

I think it depends on how much you have to customize the final product, and how customized code is handled. For example, if you have an application that displays a subfile with a single 79-character output field, and the application program puts data into that field using different data structures depending on some internal logic, it's very hard for the JSP to determine which columns actually contain field data. This requires some customization of the JSP, probably using substrings. Let's say you regenerate the project - the regenerated JSP would not have the customizations, and you'd have to restore the customized version. In this case, there's a real need to be able to generate only the new code. If your customization tool provides an easy way to access and store customized code separate from the generated code, a full regen is fine, but if it overlays the customizations, you might not want to automatically regenerate the entire project when you add a new program. Joe

[Guest.Visitor]

Hi Joe, How I read the original post was that Lluís had added additional DDS members to his project, converted them and was wondering how to best get that delta to his running web app. Note that I was NOT proposing that he should re-convert the entire app. Your append to the thread has to do with how to handle modify a jsp then re-converting the DDS member that would cause the modified JSP to be re-generated. This is certainly a trickier thing to deal with. Probably the easiest way to handle that in the long run is to modify the green screen app & DDS to break things up into separate fields (if that is what is desired as in the example you give). Then you would not have the tedium of re-customization if you need to change the app's DDS for some other reason. However, this is just my approach as I don't like having to redo things :-). Your mileage may vary... Mike Joe Pluta wrote: >I think it depends on how much you have to customize the final product, and how customized code is handled. > >For example, if you have an application that displays a subfile with a single 79-character output field, and the application program puts data into that field using different data structures depending on some internal logic, it's very hard for the JSP to determine which columns actually contain field data. This requires some customization of the JSP, probably using substrings. Let's say you regenerate the project - the regenerated JSP would not have the customizations, and you'd have to restore the customized version. > >In this case, there's a real need to be able to generate only the new code. If your customization tool provides an easy way to access and store customized code separate from the generated code, a full regen is fine, but if it overlays the customizations, you might not want to automatically regenerate the entire project when you add a new program. > >Joe > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com

[David Abramowitz]

The concept of Webfacing as I understand it, is that you do not have to alter existing applications. An existing application may be cohesive, and together in a single library. But empiricism proves otherwise. The application may be spread over many libraries, with some DDS being a part of the application, and some DDS not being a part. Just the act of determining what is, and what isn't in a particular "project" can be a project all to itself. Most applications have been developed over a period of years, in some cases decades. My users may have a requiremnent of doing something in a particular way. While I may present alternatives, I don't force them into uncomfortable situations. If I find that it is easier to add a single DDS or program to Webfacing, rather than the entire app, then IBM should also not force the issue. Dave

[Guest.Visitor]

David, This must be one of the most confusing threads going. I simply recommend to one user that the simplest way to update the changes made to his WebFacing project is to export (publish) the entire webapp because _I_ think it is the easiest way to handle this. It appears that you may have interpreted this as saying that he must WebFace the entire iSeries application. This is likely because of the use of terminology. That is, in the WebFacing Tool a "project" is the container for all the parts that constitute a WebFacing webapp. There is certainly no necessity for the WebFacing project to contain anything other than what you want in it. Sorry for the confusion. Mike David Abramowitz wrote: >The concept of Webfacing as I understand it, is that you do not have to alter existing applications. > >An existing application may be cohesive, and together in a single library. But empiricism proves otherwise. > >The application may be spread over many libraries, with some DDS being a part of the application, and some DDS not being a part. Just the act of determining what is, and what isn't in a particular "project" can be a project all to itself. Most applications have been developed over a period of years, in some cases decades. > >My users may have a requiremnent of doing something in a particular way. While I may present alternatives, I don't force them into uncomfortable situations. If I find that it is easier to add a single DDS or program to Webfacing, rather than the entire app, then IBM should also not force the issue. > >Dave > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com

[Guest.Visitor]

Hi Joe, Way back in time Lluís asked "When i add a new DDS to an existing webfacing project, convert this DDS and, what parts of this project have i to export? " To which I answered "The simplest, best and most sure thing would be to re-export it all." I never said to create a new project. How did you get that idea? The "export" that we are referring to here is simply publishing the webapp. With any software thingie (technical term there) it's a good idea to break it down into manageable chunks. This is as true for WebFacing as for C++. As to re-writing application code to suit a particular tool, well sometimes it is worth the effort and sometimes not. There is not fer-sure-works-every-time rule, at least not one that I know. It often depends upon how frequently the tool needs to be run, how severe the recover post run, etc. Sometimes, as in your case, the solution is to expand the tool's capabilities. Kind regards, Mike Joe Pluta wrote: >"How I read the original post was that Lluís had added additional DDS members to his project, converted them and was wondering how to best get that delta to his running web app. Note that I was NOT proposing that he should re-convert the entire app." > >You suggested he "export the whole project". Were you suggesting that every time that Luis adds a new program or two, he create a new project? I'm just wondering, because we're finding that the project management aspects, especially on large projects, are far more difficult to handle than the actual conversion. > >"Probably the easiest way to handle that in the long run is to modify the green screen app & DDS to break things up into separate fields (if that is what is desired as in the example you give)." > >I'm not sure who it is easiest for. For the tool designer, certainly. That's what I always suggest - rewrite your programs to fit my tool. But the reality is that clients don't like to have to muck about in working programs. > >A case in point: I recently had to add support for when a subfile was written to before it was cleared. I've never run into this before; every program I had ever seen did a WRITE with SFLCLR enabled prior to filling the subfile (SFLINZ subfiles are a different matter, because they're pre-filled). However, this program didn't have that initial clear. Now, it was a fairly minor change to add a simple WRITE at the beginning of the program, but the client didn't like making even that small of a modification. So, I added support for the WRITE without a clear. Imagine their chagrin if I told them the best way for them to use my tool was to rewrite several rather large programs. This same client has nearly 1000 programs to convert, test and customize, and a matter of weeks to do it in (which we're on track for, by the way), and having to take someone fulltime to rewrite programs isn't in the budget. > >So, instead, we have a "template" folder and a "custom" folder. The template folder holds the generated code, while the client can make as many custom folders as they want (depending on how many different "looks" they need). When the initial program changes, they regenerate the template and then retrofit the changes into the customized views. Not an optimal approach by any means, but much more palatable to the client than having to rewrite their working code. > >Joe > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com

[J.Pluta]

I think it's probably just a matter of terminology, Mike. Lluis said: "When i add a new DDS to an existing webfacing project, convert this DDS and, what parts of this project have i to export?" You said: "I think that if you are unsure then the best thing would be to simply re-export the entire thing." The phrase that's causing the misunderstanding is "the entire thing". I take this to mean the whole project, perhaps I'm mistaken. My concern is that if Lluis has ten programs already in his project, and he has customized the generated code, what happens if he adds an eleventh and then exports "the whole thing"? Does he lose his customizations? That's why I was talking about aadding a new project when adding a new program - this would allow him to export that project without disturbing previous customizations, although it would be more work from a management standpoint. Joe

[Guest.Visitor]

Right, it is just terminology, when someone says "Export" when they are talking about WebFacing then you might read that as "Publish". For example I might export my project to a .war file. The operation of taking DDS and generating web stuff we call "Conversion". Conversion of new DDS (as Lluís has done) would not over-write previous conversions (or customizations). Mike Joe Pluta wrote: >I think it's probably just a matter of terminology, Mike. > >Lluis said: "When i add a new DDS to an existing webfacing project, convert this DDS and, what parts of this project have i to export?" > >You said: "I think that if you are unsure then the best thing would be to simply re-export the entire thing." > >The phrase that's causing the misunderstanding is "the entire thing". I take this to mean the whole project, perhaps I'm mistaken. My concern is that if Lluis has ten programs already in his project, and he has customized the generated code, what happens if he adds an eleventh and then exports "the whole thing"? Does he lose his customizations? > >That's why I was talking about aadding a new project when adding a new program - this would allow him to export that project without disturbing previous customizations, although it would be more work from a management standpoint. > >Joe > -- Mike Hockings, P.Eng. WebSphere Development Tools for AS/400 - CODE/Designer & WebFacing ! IBM Canada Ltd., Laboratory hockings@ca.ibm.com