[forge-dev] Data access logic used by scaffold code

[Lincoln Baxter, III]

Yes. +1 to additional scaffolds that take advantage of all of these
features and show off everything we can do!

Also, let's not forget that we can always find clever ways to add plugins
to change the behavior of a scaffold, to tie in new frameworks like was
done with the PrettyFaces plugin - which detects when resources have been
generated, and automatically provides URL-mappings for them. Or the OCPsoft
Rewrite plugin that literally maps all scaffolded resources using one line
of config.

Let's not forget about plugin love! Creating plugins that can operate on
any scaffold is the Future!!!

~Lincoln

On Tue, Jan 24, 2012 at 9:13 PM, Richard Kennard <
richard at kennardconsulting.com> wrote:

> And don't forget Ryan Bradley is working hard on a Spring scaffold too.
>
> On 25/01/2012 11:44 AM, Richard Kennard wrote:
> > +1 for a second scaffold.
> >
> > Clearly the current scaffold is not doing much to further my clandestine
> goal of runtime UI generation. I'd definitely want to explore a second
> scaffold
> > that depends on a runtime Metawidget (much as Forge Beta 3 did). And
> probably something like CDI Query, RichFaces, PrettyFaces etc. as well.
> >
> > On 25/01/2012 11:34 AM, Dan Allen wrote:
> >> On Tue, Jan 24, 2012 at 17:19, Richard Kennard <
> richard at kennardconsulting.com <mailto:richard at kennardconsulting.com>>
> wrote:
> >>
> >>     Dan,
> >>
> >> > Can we agree to at least try to move some of the boilerplate into an
> embedded framework rather than have the common logic duplicated in each
> view bean
> >>
> >>     I'd actually be against this.
> >>
> >>     I don't think we can have an embedded framework without it being
> non-trivial. It's probably going to use unusual methods like
> >> 'getGenericSuperClass', or
> >>     declare proprietary interfaces like 'EntityWithId', or use
> non-obvious tricks like
> >>
> https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/conversion/ObjectConverter.java
> >>
> >>     So it'll need to be properly documented. Plus frameworks have a
> habit of growing. They'll need bug fixes, feature requests, examples etc.
> >>
> >>
> >> After I laid down last night, this thought (i.e, fear) came rushing
> into my head. Shading in framework code is no good (like a bad hangover
> tells you
> >> about that last shot you did the night before).
> >>
> >> ^ The beginning of Hangover 2 just came to mind :)
> >>
> >>
> >>     I don't think we should try and 'slip something like this past' as
> part of Forge. I'd be 100% behind creating something that is run as a
> top-level
> >>     project:
> >>     a Seam CRUD framework (like CDI Query) or something. And Forge
> could use that. But I think it's too big to be part of Forge itself.
> >>
> >>
> >> Ah, just wait for it. DeltaSpike Qu... ;) Coming soon to a git
> repository.
> >>
> >>
> >>     I agree that many developers, when they first see the Forge output,
> are going to immediately think "oh I could improve this, I could refactor
> that,
> >>     oh look
> >>     I could push that into a base class". There's something implicit in
> that, which is that they've immediately grok'ed the output and are moving
> on to
> >>     better
> >>     things. That's not such a bad achievement. In my opinion it's
> better than a lot of code generators (like, say, Roo) where your first
> thought is "so
> >> where
> >>     is the code that actually saves my entity? How does that get
> called? What plumbing is this?"
> >>
> >>
> >> Very true.
> >>
> >> As I said in my other e-mail, we can sort of agree to disagree in part.
> The pure Java EE approach will likely invoke the reaction of "I could
> improve
> >> that", and they would be correct. But the output is not doing anything
> cryptic, so it fills a void of showing them what Java EE has, for better or
> for
> >> worse.
> >>
> >> I'm guessing you would agree that using a few frameworks would
> dramatically improve the elegance of the output, for example Query and
> MetaWidget.
> >> Therefore it's worth the community (at least) exploring a second
> scaffold that does make use of a palatable set of extension libraries.
> >>
> >> -Dan
> >>
> >> --
> >> Dan Allen
> >> Principal Software Engineer, Red Hat | Author of Seam in Action
> >> Registered Linux User #231597
> >>
> >> http://google.com/profiles/dan.j.allen
> >> http://mojavelinux.com
> >> http://mojavelinux.com/seaminaction
> >>
> >>
> >>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
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/forge-dev/attachments/20120125/c1d21462/attachment.html