maybe, we should just do it the web controller way for this exercise to get feet wet with coding but still talk about a taglib policy?
On 3/13/07, Cynick Young <[EMAIL PROTECTED]> wrote: > > From a quick glance of the documentation, I couldn't figure out the > execution flow of when the email gets sent. > Does the tag generate a form that contains all the parameters to be sent > in the next request? > Or does the email get sent when the tag is parsed on whatever jsp page > it is on? > I think it is important for us to understand the execution flow of the > jsp tag technique before we decide to use it. > Could you look into it further and report back on that? > > In addition, I see the following challenges with going with a jsp tag > solution. > 1) We are trying to create an application which has distinct separation > between presentation and business logic. > 2) There are many business logic questions associated with the > "forgotten password" problem > i.e. > a) What happens if the email address entered is not actually in the > system? > b) How do we handle users who have not entered an email address into > their profile information? > etc. > 3) Can we maintain the separation of business logic and presentation > while using the jsp tag library? > 4) We are also trying to build a core portal which is extensible What > are the implications for portal development if we use > the jsp tags. How extensible will the solution be? > What do you think? > > Cynick > > > Anthony Perritano wrote: > > i just found this: > > > > apache has a set of open taglibs for jsps, they have one for mailing. > > > > http://jakarta.apache.org/taglibs/doc/mailer-doc/intro.html > > <http://jakarta.apache.org/taglibs/doc/mailer-doc/intro.html> > > > > my question is what do we gain by writing core functionality to do it, > > rather than use a pre made taglib? > > > > -Tony > > > > > > On 3/12/07, *Cynick Young * <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Why don't we put it into the pas portal project for now. We'll > worry > > about the future when we get there. :) > > Since the pas portal and the tels portal will be using the same > > functionality, let's add this to the core code in the package > > net.sf.sail.webappp. > > If it turns out to be useful and a much nicer wrapper api than the > > awful > > javamail piece of crap api, we can always extract it into its own > > project. > > > > Cynick > > > > Anthony Perritano wrote: > > > sounds good. what project should this go in? a new one? > > authoring and > > > plr could use this in the future? -Tony > > > > > > On 3/12/07, *Cynick Young* < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>> wrote: > > > > > > Sorry Tony. To clarify: > > > > > > > so are u saying don't use javamail? > > > > > > No, what I mean is that if you choose to use javamail as the > > > underlying > > > technology, we should still provide a higher level abstraction > > > that will > > > not require any knowledge of things like smtp server, > > > mime-encoding , or > > > character-encoding, etc. Just a simple facade that deals with > > > recipient, subject, and message. The other stuff is usually > > > boilerplate > > > code that is repeated and is implementation specific. Let's > > abstract > > > the functionality from the implementation. > > > > > > So maybe start with something like: > > > emailer.sendPlainTextMessage(EmailRecipient emailRecipient, > > String > > > subject, String message); > > > > > > In terms of testing, my first approach would be to unit test > > it using > > > some kind of mock object for the actual email transport. So > if > > > possible, mock the smtp or mock portions of the javamail so > > that it > > > doesn't actually connect to an smtp and send out mail. This > > would > > > be to > > > verify that all the motions of sending out emails are correct. > > > > > > Then, secondary testing would be an integration test where a > > real smtp > > > transport is used and a real email is sent out. But this is > > much more > > > involved and some thought needs to be put into how to verify > > that > > > email > > > was successfully delivered. > > > > > > What do you think? > > > > > > Cynick > > > > > > Anthony Perritano wrote: > > > > this sounds good. can you clarify abit. lets start with the > > > first bullet: > > > > > > > > 1. Write a component (or some components) along with unit > > tests > > > that > > > > provide a high level abstraction to sending out an email > > with a > > > template > > > > message. Javamail is too low level and too much repetitive > > > boilerplate > > > > code. > > > > > > > > so are u saying don't use javamail? > > > > > > > > we have a class that all ready in PAR > > > > > > > > > > org.telscenter.pas.ui.beans.issueReporter.actions.ReportIssueAction > > > > > > > > that sends out an email. > > > > > > > > is there a better way to do this on for web stuff? > > > > > > > > if so, what are the steps, too make this abstraction and > unit > > > test it? > > > > > > > > On 3/12/07, * Cynick Young* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> > > > > <mailto: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]> > > > <mailto: [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>>>> wrote: > > > > > > > > Hi Tony, > > > > > > > > I hear from Hiroki that you're eager to start coding and > > > perhaps you > > > > were interested in doing some work in the area of > password > > > recovery > > > > using email. That would be a good place to get your > feet > > > wet with > > > > the > > > > portal code, doing the server side processing first > > and then add > > > > on the UI. > > > > > > > > So here are my suggestions for proceeding: > > > > > > > > 1. Write a component (or some components) along with > unit > > > tests that > > > > provide a high level abstraction to sending out an > > email with a > > > > template > > > > message. Javamail is too low level and too much > > repetitive > > > > boilerplate > > > > code. > > > > > > > > 2. Add to UserDetailsDao interface to retrieve a > > > > MutableUserDetails from > > > > the data store by a given email address. Then > > implement it and > > > > write an > > > > automated integration test for HibernateUserDetailsDao. > > > > > > > > 3. Write a service to implement the logic for > > recovering the > > > password > > > > for a given email using the DAO and then sending out the > > > email using > > > > whatever the components are from #1. > > > > > > > > 4. Write a controller, validator, and jsp to add the UI. > > > > > > > > Hiroki had a sampling of working with DAOs (#2) so he > > may be > > > able to > > > > help you out with that process. I don't imagine any > > portal > > > specific > > > > details in #1 so you shouldn't have any problems > > getting started > > > > with it. > > > > > > > > Let me know if I can help. > > > > > > > > Cynick > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
