× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



David

<verndor response>
We do have a PDF API that lets you write PDF files from RPG programs. I don't work with it much, Richard wrote it. But if interested in more information, please feel free to look at our site, www.rjssoftware.com - of call 888.rjs.soft in the US - that is toll-free here, not sure how international works. Or 952.736.5800 - ask for me or Richard. Or sales.

You could also email sales@xxxxxxxxxxxxxxx
</verndor response>

Regards
Vern

David FOXWELL wrote:
I realise that I would not have had a problem if the program responsable for the display was also in RPG. The problem I have with the XSL is that some of the business programming is taking place within it. For instance, the XSL needs to compare database fields that have been written into XML documents using the same constants that are declared throughout our RPG programs.

For example, a page header that is formatted depending on the client type.
In RPG we might have in a copybook

D gCLIENT_TYPE_ONE C CONST('X001')

And in XSL I see something like <xsl:if test select="$myVariable='X001'">


We are actually generating pdf files using XSL in conjunction with fo. Would there be a solution in RPG for this ?

Thanks






-----Message d'origine-----
De : rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] De la part de Adam Glauser
Envoyé : mercredi 18 mars 2009 18:34
À : rpg400-l@xxxxxxxxxxxx
Objet : Re: Less RPG in our shop

> On 18/03/2009, at 11:35 PM, David FOXWELL wrote:
>> I wrote a post recently where I mentioned that I was using XSL in >> conjunction with XML documents created by RPG programs.
>>
>> I am worried when I see the amount of programming in the XSL files >> that is effectively taken out of the RPG program.
>> I would like your opinions on this subject. Am I wrong to say that >> the RPG program should do as much of the processing as possible?

Simon Coulter wrote:
Ask yourself this: If you were using RPG and display files would you
do the editing of dates or numeric values in the RPG or in the DDS?
It's the same here. Separation of duties is always a good thing--let
the presentation manager handle presenting the data according to how
the user wants to see it. This is really just another form of MVC. Who
is responsible for editing data? The Model, the View, or the Controller?

I agree with Simon on this point, but I think it's worth noting that you could still have an all-RPG solution as well as keeping a nice modular design.

You could have an RPG program that reads the XML and produces HTML, as well as another RPG program that reads the XML and writes it to a display file.

Essentially it comes down to the question of using the right tool for the job. If XSL has advantages in such as speed of development, maintainability or flexibility, then you need to decide whether those advantages justify the added cost of learning the new language and/or having it as a hiring requirement.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.