Some design feedback: 1. If the email address entered in the Lost Password tool is not in the WISE registry, then we return an error message indicating ³Email address not recognized² and prompt the User to try again. See the design docs for a visual example.
2. Teachers must enter an email address to complete their registration. So we¹ll always have an email associated with each teacher account. Note that the Lost Password tool for students does not give them the option of entering their email. They can either go talk to their teacher, or they can look up all the UserNames for a given Project Code. See the design docs for visual examples. Hope this helps, MattFish From: Anthony Perritano <[EMAIL PROTECTED]> Reply-To: <[email protected]> Date: Tue, 13 Mar 2007 15:25:03 -0700 To: Cynick Young <[EMAIL PROTECTED]>, <[email protected]> Subject: [SAIL-Dev] password tool i am redirecting this to the mailing list so it can be archived. 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? wouldn't the user service come back either "email" or "no email" found? i see where u are coming from this breaks some of the separation of business logic, ui and controller. so this asks questions-do we really want to re implement some that is already tested and established? the apache libraries are pretty widely used. using some of these libraries breaks the separation. it depends how strict do we want to be with this separation. for a simple password recovery tool do we want to reimplement or use the taglib. for more major parts of the system we should break it up in this separation. i see in the future, as more people get on in portal development there is going to more of a use of taglibs as time towards deadlines decreases. so maybe we should come up with a policy on using taglibs, for some contained small tools like recovering a password? or maybe this is too big of a component, may be could come up with another example? answer to 4) would be is that it is all ready extensible. they could not use the tag lib and then build their own mail controller etc... i think the flow would be "user fills our form with email presses submit" -> "user services looks up email and returns the email or no email" -> "display error page or yr email was sent..." ???? -Tony 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]> >> > <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]> <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 -~----------~----~----~----~------~----~------~--~---
