9:46 p.m.
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. Being able to change
configuration while the server is running, seeing your changes immediately,
is a huge benefit for productivity.
I don't know if Seam2 provided runtime config reloading, but I would
hesitate use a Java-based option. There are places where XML is useful, as
long as it is kept simple. In my opinion, we need to be really careful when
applying annotations/single objects to concepts with which they do not
directly align, or "fit," in a one-to-one manner.
The enumeration concept is interesting because, unlike classes, enums do not
claim to be anything more than "a representation of a set of concepts and
some standard behaviors."
public enum MyAppPage implements Page<MyAppPage> {
@View(.....)
login {
@Inject Login loginBean;
public MyAppPage next(MyAppPage page, Object outcome) {
if ( loginBean.isLoggedIn() )
return main;
else
return login;
}
}
}
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;
}
},
@View(.....)
logout {
public MyAppPage next(MyAppPage page, Object outcome) {
return login;
}
};
Also, how will this address the bookmarkability issue? How are parameters
passed between pages? -- Pages.xml used explicit syntax for parameter
passing:
<param name="documentId" value="#{documentEditor.documentId}"/>
Which would be difficult to translate into an Enum solution like the one
that Gavin suggested. I'm not seeing an immediate solution, save adding an
additional method that returns a list of parameter names and expressions to
be propagated, but now we're talking about a lot of boilerplate code in
order to do something simple.
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.
Thoughts?
Lincoln
On Fri, Feb 19, 2010 at 4:03 PM, Marcell Manfrin Barbacena <
barbacena(a)gmail.com> wrote:
I posted this sometime ago and I think it relates to this then I am
re-posting:
--
One of the things I would like to have is something like a plugable
application module with JSF as in:
http://wicketinaction.com/2008/10/creating-pluggable-applications-with-wi...
However if we stick with wicket to get the view part modularity the
only thing necessary to have is a way to retreive all avaliable beans
with a given Steriotype or Qualifier (the spring way is
BeanFactoryUtils.beansOfTypeIncludingAncestors)
--
I think doing this pages configuration in java we could do the same
feature with jsf. (But we would also need a bit more)
[]s
===
"Our deepest fear is not that we are inadequate.
Our deepest fear is that we are powerful beyond measure.
It is our light, not our darkness that most frightens us.
Your playing small does not serve the world.
There is nothing enlightened about shrinking so that other people
won't feel insecure around you.
We are all meant to shine.
And as we let our own light shine, we unconsciously give other people
permission to do the same.
As we are liberated from our own fear, our presence automatically
liberates others."
by Marianne Williamson
--
Marcell Manfrin Barbacena
barbacena(a)gmail.com
marcell(a)tre-pb.gov.br
Skype: callto://marcell84bruk
+55 (83) 8808-8555 (Mobile)
+55 (83) 3224-5945 (Home)
On Fri, Feb 19, 2010 at 5:51 PM, Arbi Sookazian <asookazian(a)gmail.com>
wrote:
> Seam has a relatively small number of (mostly static) xml config files
> (thank God). I'm not sure it's even necessary to convert the pages.xml
to a
> class or even if all users would want that. Yes, type safety is good,
but
> it's easier to read in xml format sometimes. If you leave the option of
> class or xml then it's ok.
>
> Is the Page class/enum going to be something that is extended or
> polymorphic, etc? Why convert to OO if the only reason is type-safety
> assurance in this case (plz don't beat this comment down, yes, maybe I'm
> missing something).
>
> It would be pretty cool if there was a new utility that converted a
> pages.xml to class/OO format...
>
> On Fri, Feb 19, 2010 at 12:35 PM, Stuart Douglas
> <stuart(a)baileyroberts.com.au> wrote:
>>
>> find . | grep xhtml | wc
>> 392 392 21192
>>
>> It's going to be a big enum... we would need to make sure that you could
>> split it up.
>>
>> The only real problem I have with this approach is that all the metadata
>> that is availible is hard coded into the page class, which means the
page
>> class has to know about every module that wants to use page level
metadata.
>> Also, you can't really configure it via xml, which I am not too worried
>> about but may alienate some users.
>>
>> Stuart
>>
>> On 19/02/2010, at 4:40 PM, Gavin King wrote:
>>
>> > You should even be able to make this work:
>> >
>> > @View(.....)
>> > login {
>> > @Inject Login loginBean;
>> > public MyAppPage next(MyAppPage page, Object outcome) {
>> > if ( loginBean.isLoggedIn() )
>> > return main;
>> > else
>> > return login;
>> > }
>> > },
>> >
>> > of course we would need a little infrastructure for injecting into
enum
>> > values.
>> >
>> > On Thu, Feb 18, 2010 at 11:37 PM, Gavin King <gavin.king(a)gmail.com>
>> > wrote:
>> >> Oops, this is a MUCH better way to write this code:
>> >>
>> >>
>> >> public enum MyAppPage implements Page<MyAppPage> {
>> >>
>> >> @View(.....)
>> >> login {
>> >> public MyAppPage next(MyAppPage page, Object outcome) {
>> >> if (Boolean.TRUE.equals(outcome))
>> >> return main;
>> >> else
>> >> return login;
>> >> }
>> >> },
>> >>
>> >> @View(.....)
>> >> main {
>> >> public MyAppPage next(MyAppPage page, Object outcome) {
>> >> return main;
>> >> }
>> >> },
>> >>
>> >> @View(.....)
>> >> logout {
>> >> public MyAppPage next(MyAppPage page, Object outcome) {
>> >> return login;
>> >> }
>> >> };
>> >>
>> >> }
>> >>
>> >
>> >
>> >
>> > --
>> > Gavin King
>> > gavin.king(a)gmail.com
>> > http://in.relation.to/Bloggers/Gavin
>> > http://hibernate.org
>> > http://seamframework.org
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
10:53 p.m.
New subject: [weld-dev] Replacing pages.xml
On Thu, Mar 4, 2010 at 3:46 PM, Lincoln Baxter, III
<lincolnbaxter(a)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(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
4:29 p.m.
New subject: [weld-dev] Replacing pages.xml
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(a)gmail.com> wrote:
On Thu, Mar 4, 2010 at 3:46 PM, Lincoln Baxter, III
<lincolnbaxter(a)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(a)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"
4:31 p.m.
New subject: [weld-dev] Replacing pages.xml
On 10 Mar 2010, at 15:29, Lincoln Baxter, III wrote:
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.
We can't do it in plain CDI, but a portable extension can be written to do this (well,
it can be added to Weld extensions).
5168
days inactive
5174
days old
3 comments
3 participants
participants (3)
-
Gavin King -
Lincoln Baxter, III -
Pete Muir