On Mar 13, 6:25 pm, "Anthony Perritano" <[EMAIL PROTECTED]> wrote: > 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?
Yes, the user service should have the logic. > 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. I am all for using tested and established libraries. As a matter of fact, I'm using lots of apache libraries like httpclient, commons- dbcp, commons-lang... I am also not against using taglibs and I'm already using jstl, spring tags, displaytags... My requirement is that we use the right tool for the right job! And the right tool is partially constrained by the ability to keep the separation of layers in the architecture I'm trying to maintain for this codebase. > 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. I don't want to reimplement anything that already works the way we need it to work. If using the taglib will still allow us to separate our logic from the presentation, then use it. If not, then it's not the right tool. This is evaluation. > 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? What constitutes a big component or a small component? What components should be exempted from the logic separation? > > 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... > And you could not use the existing php pages in wise and change them with different php pages, php is extensible. Why would you want to reimplement wise when it's already tested and established? > 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..." > > ???? > In terms of flow, I was thinking more of: the request hits the server - > the submission input is validated -> the controller calls the service -> the service verifies the email address -> email is sent out -> the controller decides which page to display -> the view is returned. By using the taglib, the email is sent out in the same step as the view is returned because it's part of the jsp view. So, the user will get a page that says your email was sent even when there happens to be some kind of error condition like the smtp server is down or configured improperly or the wrong parameters are passed to the taglib. > -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]>> 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 > > ... > > read more ยป --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
