Hi guys, Will pdf and mail be separate modules? I would also like to contribute to both modules. I have done some extensive research of existing mail module code while tracking down JBSEAM-3555 and have found out that current approach to using JSF in seam mail error-prone J Currently seam just uses jsf that was initalized in web application and that is why there are some ugly hacks to make it work when you invoke seam mail from from non-web request (ejb,mdb,...) Pete has sugessted that new seam-mail modul should start its own instance of JSF. Main problem with jsf is that there is no standard api to programaticly set-up jsf enviroment. Idea is that seam implements RI (Mojarra 2.0) with implementation specific api and possible others if they provide any machins for starting up. I would also like to contribute do pdf module as we have some in-house improvments and also some friends are willing to contibute huge upgrade to seam-pdf(forms,etc,..) but it is currently seam 2.0.x based. As I have not yet had much time to dive deeply into CDI and Seam 3(but I folow development closly) a kick start as setting up seam3 module would be much apreciated. Altough I can help to >rip out< any seam 2 module... Cheers, Tomaž From: seam-dev-bounces(a)lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Lincoln Baxter, III Sent: Thursday, May 20, 2010 4:57 PM To: cody.lerum(a)gmail.com; Dan Allen; Seam Dev List Subject: [seam-dev] Let me know what you need for a first stab at the PDF/Mail port from Seam 2 Hi Cody, you have my email address now. I'm actually not very familiar with Seam 2, which is one of the reasons this has been lower priority, but if you can "rip" that part out of Seam 2 and make it a standalone maven project, I can help you get it set up as a Seam 3 module and all that goodness :) seam-dev(a)lists.jboss.org (if you don't already know) is where we discuss development, so you can also ask questions there -- https://lists.jboss.org/mailman/listinfo/seam-dev is where you can sign up. Thanks for reaching out! -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" !DSPAM:6,4bf54e13248112142088973!

I think for now these should be the same module. "Seam Docs" -- There's also been speculation on whether a Mock Framework could be used to boot-up JSF and render documents. http://community.jboss.org/wiki/MockObjectsforTestDrivenJSFDevelopmentorg... Another alternative is to build a UIViewRoot, and replace it during the PreRenderViewEvent (which specifically states that it can be used to replace the UIViewRoot.) Or.. there's the possibility of simply creating a "fake" Request and Response object, and doing an internal forward in order to capture output and capture the output (via the faked response object) to be used in generating the PDF or Mail document. This last option is probably where I would start. I'd start by simply trying to create a new request and capture the output -- just try on a normal page, we can worry about generating pages that look like email documents after this basic functionality is working. --Lincoln 2010/5/21 Cody Lerum <cody.lerum(a)gmail.com&gt; -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

On 21 May 2010, at 16:24, Lincoln Baxter, III wrote: Yes, no reason not to bundle Mail - it's easy to ignore those tags you don't want. Just make sure to keep the code split up...

This is an idea that we had. Would be interested in feedback from people working with production systems, is this something they would allow? It's certainly very clean to implement. On 22 May 2010, at 08:08, Jason Porter wrote:

On 24 May 2010, at 14:35, denis.forveille(a)gmail.com wrote: The proposal was to push it through the loopback interface, not to a remote interface. Yes it does, you would get the PDF back, and can do whatever you like with it. Right, this is the current debate. This points (yet again) that the real answer is to have an "embeddable" JSF which can run outside the web container. Unfortunately we seem to be a long way away from that. Right, but we are discussing design for Seam 3, which is targeted at Java EE 6, and so is completely relevant.

On 2010/05/22 0:24, Lincoln Baxter, III wrote: Email is not really a document. It is a message, see below. All of those sound hackish to me. Consider that people will also want to persist the email (DB/file). Any way you look at it, email is not a web page. It is not a regular document either. It has a recipient, headers, reply-to, and is much closer to JMS (guess where the inspiration for JMS came from...) than a regular document. How about: * a custom context that can hold the info you need to render the email (or just a use map of strings) * a renderer independent of view technologies, that has a pluggable templating engine * templating engine (Velocity, regex, whatever, even JSF if people love it so much) * easliy pluggable transport(s), so that you can send, save, save+send or just pipe your email to whatever needs to process it next.

On Sun, May 23, 2010 at 8:17 PM, Nikolay Elenkov <nick(a)sarion.co.jp&gt; wrote: Huh?! What on earth does velocity have that makes it a "real" templating engine that facelets does not have? I have used both, and I found velocity far, far poorer in both syntax and semantics. Why? Cos XML files are not text files? Cos #foo #end is easier to edit than <foo></end>? I don't see how what you just wrote can possibly be true. They are XML files. I can't imagine a Java developer who doesn't know XML. I do know several Java developers who find velocity syntax nausea-inducing. I'm one of them. The only reason for them to be xhtml files is if you are sending HTML-format email. Please try actually reading the Seam mail documentation: http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/mail.html I don't see how most of the functionality could be achieved in velocity, eg. <m:from>, <m:to>, <m:subject>, <m:header>. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

Nikolay, I think it would help people understand your proposal better if you gave an example of your proposed syntax using another templating engine. Perhaps take one of the example emails from Seam2 and rewrite it... On 24 May 2010, at 05:01, Nikolay Elenkov wrote:

On 24 May 2010, at 16:47, Lincoln Baxter, III wrote: So far I've heard one person say this. I've heard 10-100s say they really like using JSF. Right now, JSF is the key thing to get implemented.

I just don't buy this. On the contrary, the Seam mail functionality is NOT just rendering a bit of text, which is what I tried to explain, but nobody seems to be "getting". The template actually builds an object, with to/from addresses, a subject line, headers, etc. On Mon, May 24, 2010 at 12:55 PM, Jason Porter <lightguard.jp(a)gmail.com&gt; wrote: -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

On 24 May 2010, at 19:06, Gavin King wrote: Right, and I believe that it is pretty natural to use. I've heard many people say they really like the simplicity/power of using facelets to template their email, and the consistency with writing pages for the web. What I always hear though is that people would like to use this outside of a web request (e.g. as part of a batch process or in an MDB). So, I suggest we return to this topic. Not quite sure what "these Java Objects" refers to, but with Facelets it can directly create the JavaMail objects or iText objects as part of the render, there is no need for this transform stage you describe. Not really. If you use JSF/facelets, this "transform problem" goes away, and is replaced with the problem of how to make JSF work outside a web request. Well, yes, of course we are taking advantage of the facilities that the templating engine we have offers. To not do so would be madness (aka reinventing the wheel).

I'm making it a point, if it's not already, yes ;) On Mon, May 24, 2010 at 3:34 PM, Jason Porter <lightguard.jp(a)gmail.com&gt;wrote: > On Mon, May 24, 2010 at 12:40, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > > > > > On 24 May 2010, at 19:06, Gavin King wrote: > > > >> And, of course, this is why facelets is so appropriate for the task: > >> facelets was designed not for text rendering, but for object graph > >> construction. JSP and Velocity just render text. > > > > Right, and I believe that it is pretty natural to use. I've heard many > people say they really like the simplicity/power of using facelets to > template their email, and the consistency with writing pages for the web. > > > > What I always hear though is that people would like to use this outside > of a web request (e.g. as part of a batch process or in an MDB). So, I > suggest we return to this topic. > > > >> > >> On Mon, May 24, 2010 at 1:04 PM, Gavin King <gavin.king(a)gmail.com&gt; > wrote: > >>> I just don't buy this. On the contrary, the Seam mail functionality is > >>> NOT just rendering a bit of text, which is what I tried to explain, > >>> but nobody seems to be "getting". The template actually builds an > >>> object, with to/from addresses, a subject line, headers, etc. > >>> > >>> On Mon, May 24, 2010 at 12:55 PM, Jason Porter <lightguard.jp@ > gmail.com> wrote: > >>>> I wouldn't think it would be too terrible to get it to a point where > >>>> the actual template engine isn't much of a concern. Really it's how > >>>> do I take these Java Objects I've built up and transform them into > >>>> Java Mail / iText / jxl / etc am I right? > > > > Not quite sure what "these Java Objects" refers to, but with Facelets it > can directly create the JavaMail objects or iText objects as part of the > render, there is no need for this transform stage you describe. > > I thought that's what was happening, at least as I understand it for > PDF the page creates objects that will eventually be fed into iText, > but they're not the actual iText objects (or subclasses). I haven't > looked enough at the mail stuff to know if that's what's happening or > not. So the transformation phase I was talking about is taking the > data from the tag objects (which are pretty much POJO data containers > as I understand it) and setting that data onto the iText (mail, again, > assuming) objects. > > >>>> This seems like a much > >>>> bigger problem to tackle than which template engine we use. > > > > Not really. If you use JSF/facelets, this "transform problem" goes away, > and is replaced with the problem of how to make JSF work outside a web > request. > >>>> Unfortunately the template engine is seeming to drive the backend > >>>> transformation process :( > > > > Well, yes, of course we are taking advantage of the facilities that the > templating engine we have offers. To not do so would be madness (aka > reinventing the wheel). > > > >>>> > >>>> On Mon, May 24, 2010 at 10:00, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >>>>> > >>>>> On 24 May 2010, at 16:47, Lincoln Baxter, III wrote: > >>>>> > >>>>>> If what I'm hearing is correct, people aren't so much concerned with > using JSF as a templating language, but they are concerned with having "some > kind" of templating, and the ability to access data from the current > request. > >>>>> > >>>>> So far I've heard one person say this. I've heard 10-100s say they > really like using JSF. > >>>>> > >>>>>> > >>>>>> If that's the case, then it would be incredibly easy to plug in > Velocity or another templating system and still provide this functionality. > Much easier I believe, in fact, than sledgehammering JSF into a > non-servlet-like invocation environment. > >>>>>> > >>>>>> I personally think we should start with a different templating > system (since Seam is supposed to be view-layer agnostic anyway.) But I also > think that having parallel prototyping going on is a good thing, we can use > everyone's combined experiences with the prototypes to come up with a truly > decoupled and user-centric system. > >>>>> > >>>>> Right now, JSF is the key thing to get implemented. > >>>>> > >>>>>> > >>>>>> My big question is... JSF templating is nice, but... what do people > truly need? > >>>>>> > >>>>>> Thoughts? > >>>>>> --Lincoln > >>>>>> > >>>>>> On Mon, May 24, 2010 at 10:22 AM, Pete Muir <pmuir(a)redhat.com&gt; > wrote: > >>>>>> Nikolay, > >>>>>> > >>>>>> I think it would help people understand your proposal better if you > gave an example of your proposed syntax using another templating engine. > Perhaps take one of the example emails from Seam2 and rewrite it... > >>>>>> > >>>>>> On 24 May 2010, at 05:01, Nikolay Elenkov wrote: > >>>>>> > >>>>>>> On 2010/05/24 12:46, Gavin King wrote: > >>>>>>>> On Sun, May 23, 2010 at 8:17 PM, Nikolay Elenkov < > nick(a)sarion.co.jp&gt; wrote: > >>>>>>>> > >>>>>>>>> I don't know how much better JSF2 is at this, but is it really a > good idea to > >>>>>>>>> use JSF for the mail module? Wouldn't it be better to use a real > templating > >>>>>>>>> engine (like Velocity) and not depend on JSF? > >>>>>>>> > >>>>>>>> Huh?! What on earth does velocity have that makes it a "real" > >>>>>>>> templating engine that facelets does not have? I have used both, > and I > >>>>>>>> found velocity far, far poorer in both syntax and semantics. > >>>>>>> > >>>>>>> OK, bad wording on my part. The point was not be dependent on JSF. > I am not > >>>>>>> saying that Velocity is better. But it does allow you to have > template that > >>>>>>> are not XML files. > >>>>>>> > >>>>>>>> > >>>>>>>>> Plus it would be easier > >>>>>>>>> to edit templates if they are not xhtml files, but simple text > files. > >>>>>>>> > >>>>>>>> Why? Cos XML files are not text files? Cos #foo #end is easier to > edit > >>>>>>>> than <foo></end>? I don't see how what you just wrote can possibly > be > >>>>>>>> true. > >>>>>>> > >>>>>>> Yes, it is. Especially if you are not a developer. You can just > tell people: > >>>>>>> 'don't touch this things starting with #, otherwise just edit in > notepad'. > >>>>>>> > >>>>>>>> > >>>>>>>>> The usual > >>>>>>>>> use case for mail templating is to provide files your users can > edit if they > >>>>>>>>> want to customize how email looks like. And you can't really > expect them to > >>>>>>>>> understand xhtml. > >>>>>>>> > >>>>>>>> They are XML files. I can't imagine a Java developer who doesn't > know > >>>>>>>> XML. I do know several Java developers who find velocity syntax > >>>>>>>> nausea-inducing. I'm one of them. > >>>>>>>> > >>>>>>> > >>>>>>> Again, this is not about pro-Velocity, anit-Faceltes. The people > that would have > >>>>>>> to edit templates are *users*, not *Java developers*. If you have > to call up > >>>>>>> your developers just to change the email template, you have failed > at usability. > >>>>>>> > >>>>>>>> Please try actually reading the Seam mail documentation: > >>>>>>>> > >>>>>>>> http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/mail.html > >>>>>>> > >>>>>>> I have. I've also been thorough the source, tried to use it and > then gave up. > >>>>>>> > >>>>>>>> I don't see how most of the functionality could be achieved in > >>>>>>>> velocity, eg. <m:from>, <m:to>, <m:subject>, <m:header>. > >>>>>>>> > >>>>>>> > >>>>>>> s/velocity/any templating engine you might like/g. I am repeating > myself here, > >>>>>>> but you cannot reallisticaly expect users to mess around with > <m:header> and not > >>>>>>> break the system. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> seam-dev mailing list > >>>>>>> seam-dev(a)lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> seam-dev mailing list > >>>>>> seam-dev(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Lincoln Baxter, III > >>>>>> http://ocpsoft.com > >>>>>> http://scrumshark.com > >>>>>> "Keep it Simple" > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> seam-dev mailing list > >>>>> seam-dev(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/seam-dev > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Jason Porter > >>>> > >>>> Software Engineer > >>>> Open Source Advocate > >>>> > >>>> PGP key id: 926CCFF5 > >>>> PGP key available at: keyserver.net, pgp.mit.edu > >>>> > >>> > >>> > >>> > >>> -- > >>> Gavin King > >>> gavin.king(a)gmail.com > >>> http://in.relation.to/Bloggers/Gavin > >>> http://hibernate.org > >>> http://seamframework.org > >>> > >> > >> > >> > >> -- > >> Gavin King > >> gavin.king(a)gmail.com > >> http://in.relation.to/Bloggers/Gavin > >> http://hibernate.org > >> http://seamframework.org > > > > > > > > -- > Jason Porter > > Software Engineer > Open Source Advocate > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

On Mon, May 24, 2010 at 5:19 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: I think that depends to some extent on what transitive dependencies you get when you pull in JSF. It also depends on making it possible to use jsf and other view layers like wicket side by side in the same web deployment; in Seam2 this was not supported. (I know that it's the intent to support mixed view layers in Seam3, but this would be the first time a key Seam3 feature was JSF dependent afaik, so it will at least put that hypothesis to the test.) I've actually switched to using programmatic creation of pdf and mail for the same reason I've switched from JSF to Wicket: type safety in a large code base in the face of a continually refactored model. That argument isn't as valid for smaller code bases, but it means I care a lot less which way this particular thread goes than I would have a year ago :) -Clint -- Clint Popetz http://42lines.net Scalable Web Application Development

As we've started make concrete requirements, I've set up a JIRA project to track. For those where i've created JIRA issues, I suggest we continue the discussion there. On 25 May 2010, at 03:01, Nikolay Elenkov wrote: We always intended people to use the templating feature of Facelets (ui:include) to work around this. Did you not realize you can do this (documentation problem), or reject it? If you rejected it, why did you reject it? I've documented your comment that XML is too complex for your business analysts at https://jira.jboss.org/browse/SEAMMAIL-7 Email has two types of errors, those that the MTA will automatically retry for, and those that cause bounces. If you are referring to bounces, how do you process the bounces? https://jira.jboss.org/browse/SEAMMAIL-1 This is a "generic" requirement. I like to know the real use cases. This is on the cards. This is the problem we are trying to solve ;-) Would like to understand more about your problems here. Agreed. This is definitely something we should work on. https://jira.jboss.org/browse/SEAMMAIL-2 We could easily introduce a component that takes multiple to addresses (e.g. a Collection). Not sure why I didn't do this originally ;-) https://jira.jboss.org/browse/SEAMMAIL-3 Agreed. This is where this whole thread started. https://jira.jboss.org/browse/SEAMMAIL-4 Useful functionality. We should definitely put this on the roadmap. https://jira.jboss.org/browse/SEAMMAIL-5 Ok, this is definitely something to look at. https://jira.jboss.org/browse/SEAMMAIL-6 Exactly. So it's good we are now looking at your real problems, not the perceived solution. I don't think throwing out the whole templating engine, just because there are issues with the implementation is a forgone conclusion. Or, to use one of my favourite sayings, let's not throw the baby out with the bathwater.

On 2010/05/24 23:22, Pete Muir wrote: See my other email as well for why the templating engine is not the main point, but here goes (base is simple.xhtml): --------------------------------------------------------------- Subject: Try out Seam! Dear #{person.firstname}, You can try out Seam by visiting http://www.seamframework.org Regards Peter --------------------------------------------------------------- Much simpler and easier on the eyes. Anything besides that (headers, attachments) is better handled in code and users should not touch it. Since, as you say, people like the facelets templates, you should probably keep them in Seam 3, but they are not suitable for editing by users. Greet your user with this and they will give up right away.... <m:message xmlns="http://www.w3.org/1999/xhtml" xmlns:m="http://jboss.com/products/seam/mail" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html">