I don't really like that idea, as it means that forge then becomes part of your build
process.
With the @AutoHome it should not really matter about IDE auto completion, the idea is to
just register a bean that allows you to lookup beans by ID from the EL.
The underlying bean would probably look like:
public class AutoHomeBean<T,ID> {
private ID id;
private T instance;
void setId(ID id) {
if(!this.id.equals(id) ) { //need NPE check as well
this.instance = null;
}
this.id = id;
}
ID getId() //getter;
public T getInstance() {
if(instance == null && id != null) {
instance = em.find(...);
}
return instance
}
}
Then if you put the AutoHome annotation on MyEntity you would get a MyEntityHome bean
being registered, and you could then do things like:
#{myEntityHome.setId(10)};
#{myEntityHome.instance.name}
Not sure how practical / useful it will be in practice, but that was the basic idea.
Stuart
On 22/09/2011, at 8:19 AM, Dan Allen wrote:
True. I don't really see the problem with having an object that
extends a base object, even if it has no additional methods.
...and if that is the solution, then the @AutoCrud could be a hint to forge to generate
that class if it doesn't yet exist. Now that's an idea :)
-Dan
On Wed, Sep 21, 2011 at 18:17, Jason Porter <lightguard.jp(a)gmail.com> wrote:
That's good at the runtime, but develop time that really doesn't help because it
won't compile and you won't get IDE auto complete.
On Wed, Sep 21, 2011 at 16:10, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Stuart,
You also previous mentioned...
With portable extensions we could do something like:
@Entity
@AutoHome
public class MyEntity ....
and have a portable extension that registers a new home bean for every entity with the
@AutoHome annotation.
I think we all agree that "Home" is a crappy name, so perhaps @Crud or @Dao
would be a sufficient name.
-Dan
On Tue, Sep 20, 2011 at 22:15, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
My original plan for EntityQuery was to use the ServiceHandler stuff in solder:
@EntityQuery
public interface MyQuery {
@Query("Select u from User u where type=:p1")
public List<User> users(String type);
}
Stuart
On 09/21/2011 06:00 AM, José Rodolfo Freitas wrote:
> Yeah, I agree that being declarative is the ideal.
> let's say no to inheritance with generics! hehehe.
>
> On Tue, Sep 20, 2011 at 4:41 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
> On Tue, Sep 20, 2011 at 15:36, José Rodolfo Freitas
<joserodolfo.freitas(a)gmail.com> wrote:
> What I like most in CDI and Seam3 is that it's very easy to keep things simple
and that's something I strongly advocate.
>
> +1
>
> Of course there're still boilerplate code, but I think it's minimal (compared
to the JEE generations before), and that's something forge can create without the need
to satisfy a "framework". Yes, I admitedly am afraid of that word.
>
> That's fine, it doesn't have to be a framework. I do think there is room for
having some common scaffolding, though. If we can do that by extending the programming
model (annotations, generic beans or interfaces) so that it's declarative, that's
probably ideal.
>
> I suggest that we brainstorm proposals using gists (
http://gist.github.com). That
will get the ball rolling. We can start with the idea Jason posted, or feel free to take a
different approach.
>
> -Dan
>
> --
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
>
http://www.google.com/profiles/dan.j.allen#about
>
http://mojavelinux.com
>
http://mojavelinux.com/seaminaction
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at:
keyserver.net,
pgp.mit.edu
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction