[seam-dev] Let me know what you need for a first stab at the PDF/Mail port from Seam 2

Mon May 24 15:40:35 EDT 2010

>
> True, though the point of Seam being front-end agnostic is a good one.
>  Were I using Wicket for example I can't do PDF / Mail / Excel with
> Seam unless I also use JSF, I believe this is also part of the current
> debate, am I right?
>

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 at gmail.com>wrote:

> On Mon, May 24, 2010 at 12:40, Pete Muir <pmuir at redhat.com> 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 at gmail.com>
> 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.
>
> True, though the point of Seam being front-end agnostic is a good one.
>  Were I using Wicket for example I can't do PDF / Mail / Excel with
> Seam unless I also use JSF, I believe this is also part of the current
> debate, am I right?
>
> >>>> 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 at redhat.com> 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 at redhat.com>
> 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 at sarion.co.jp> 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 at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/seam-dev
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> seam-dev mailing list
> >>>>>> seam-dev at 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 at 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 at gmail.com
> >>> http://in.relation.to/Bloggers/Gavin
> >>> http://hibernate.org
> >>> http://seamframework.org
> >>>
> >>
> >>
> >>
> >> --
> >> Gavin King
> >> gavin.king at 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100524/cc43f298/attachment-0001.html 