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@kennardconsulting.com <mailto:
richard@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@lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev