[seam-dev] [weld-dev] Replacing pages.xml

[Lincoln Baxter, III]

Ok, one other issue that just crossed my mind.

This is purely a technical concern, obviously configurations can be merged,
but it would be nice if the configuration could be configured in a "Beans"
like manner, so that the Seam3 XML configuration module could consume the
Java artifacts and allow XML configuration (using the same classes,
preventing duplication, all that good stuff...)

I'm not sure if instantiating Enums and using them as beans is something
that we can do at this time (looking for someone who knows to answer this?)
so it may be worth sticking with a class interface or abstract class
concept.

Just a thought, looking for confirmation or education ;)

--Lincoln

On Thu, Mar 4, 2010 at 4:53 PM, Gavin King <gavin.king at gmail.com> wrote:

> On Thu, Mar 4, 2010 at 3:46 PM, Lincoln Baxter, III
> <lincolnbaxter at gmail.com> wrote:
> > Copying seam-dev because this seems very relevant ;)
> > --
> >
> > A pitfall with the class/annotations configuration: the potential loss of
> > ability for runtime modification during development.
>
> Well, we can make this argument against *every* effort to improve
> typesafety of the system. We can make the same argument against using
> annotations to configure dependencies.
>
> The truth is that the benefits outweigh the downsides.
>
> > This forces all navigation logic from a specific view into one Enum
> > definition, which is nicely centralized; however, I'm not sure what the
> > intent is here: Is this a no-op navigation?
> >
> >       @View(.....)
> >       main {
> >          public MyAppPage next(MyAppPage page, Object outcome) {
> >             return main;
> >          }
> >       },
>
> Right, it's like returning null from a JSF action method.
>
> > Also, how will this address the bookmarkability issue? How are parameters
> > passed between pages? -- Pages.xml used explicit syntax for parameter
> > passing:
>
> I don't claim to have solved all problems yet, but I'm sure they are
> solveable by provisions of appropriate APIs.
>
> > I'm probably going to lite a fire by saying this, but sometimes XML is
> more
> > concise than Java. I'd like to be convinced that this is a good option to
> > provide, and that it will be simpler or more usable than XML. Right now
> my
> > gut is telling me that it's going to be more complicated both for our
> > development, and the users'.
> >
> > I am a big fan of the Injectability, and I think that's a strong point
> > toward a native Java solution, but I'm not sure it's enough when you can
> > already reference beans through EL in pages.xml and get direct access to
> > both contexts and dependencies - giving you the best of both worlds in a
> > pretty reusable way.
>
> That's all very well, until something changes and you need to start
> refactoring things.
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
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/20100310/c28c048f/attachment.html