& XSLT Hi Tod,

>  I'd say the way you're proposing to do it is probably the most reliable way. 
>  OTOH both the XML and the email handler are server-side to begin with, so why 
>  does the XML itself need to be round-tripped to the web browser?

If I don't I have to store it somewhere... either in a dbm, flat file or 
database. I could store it in mysql as a temporary table tied to the perl 
process id, and then just pass the RefId (unique for each transaction) and 
then pull the selected items out of the table (just a refid field, and a 
'sent' and 'received' text field), generate the email and delete the table 
before the process exits.

I was just wondering if one couldn't find a more elegant solution by 
encoding the xml in some fashion to make it opaque to the form and then 
selected 'black boxes of data' are sent to the email function for 
extraction and emailing. No other I/O required. That was my idea... I'm 
just not sure how to make the transition from 'structurally meaningful 
XML' to 'opaque black boxes of data' and back. I also don't really need 
structural information...(ie. I'm not saving a perl data structure or dom 
tree, etc.) and just thought the Base64 encoding would be simple to do.

I'll take a whack at the first approach, and then fall back to the 'tried 
and true store in databse' approach which will also work fine.

Thanks very much for your help,

Les



>  IE it must 
>  be stored somewhere (say in a database) so can't you just send back a form 
>  that says "email transaction X information", so maybe you'd have a set of 
>  checkboxes on your web form that would just have the X values. Probably you 
>  want to display some of the info on the form, but it would seem best to just 
>  format that as HTML as part of generating the form. It makes your emailing 
>  function a bit more complex and less generic, but if it has to undo base64 
>  anyway its already pretty specific to that problem set, so why not just have 
>  it do the database lookup?
> 
>  Les Richardson wrote:
> 
> > 
> > Hi All,
> > 
> > As part of an XML transaction process with our provincial education 
> > department, I want to be able to automatically email some of the xml 
> > transactions (both sent and received portions) back to the provincial 
> > student records department so that we can have them solve the student 
> > authentication problems of certain transactions (these are typically 
> > student enrollment problems). This information is selected via feedback 
> > from a web form. (ie. administrator/secretary selects certain failed ones 
> > to email).
> > 
> > The problem: To keep things are simple as possible (and stateless), the 
> > email function should simply accept the transaction information (ie. xml 
> > sent, xml received) and email these to the student records department for 
> > resolution. (along with some other school information, etc.)
> > 
> > Can I just base64 encode the complete transaction (called a 
> > StudentSchoolEnrollment element, and the response) and then pass it as the 
> > value of a form element?  Then decode in the email generation function and 
> > put it into the text of the email?
> > 
> > This just seems ugly and perhaps a more elegant solution exists? I just 
> > want to keep things as simple as possible and don't really want to do file 
> > I/O or session management, etc.
> > 
> > Any feedback most welcome,
> > 
> > 
> > Les Richardson
> > Open Admin for Schools
> > Saskatchewan, Canada
> > _______________________________________________
> > Perl-XML mailing list
> > Perl-XML@[...].com
> > To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
> 
> 
>  _______________________________________________
>  Perl-XML mailing list
>  Perl-XML@[...].com
>  To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
> 
_______________________________________________
Perl-XML mailing list
Perl-XML@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs