if you go contract-first, there is no sense in care about later
modifications... a class never can be modified without modifying the
contract and regenerate all classes....
On Jan 13, 2008 9:00 PM, Farrukh Najmi <farrukh_at_wellfleetsoftware.com> wrote:
>
> My use case is completely "contract-first" and nothing else. However, I
> need to provide a client API based on the JAXB generated bindings that
> need to keep track of modified state of JAXB generated bindings. This
> seems to be something the bindings should be able to keep track of
> themselves by injecting some code into setter methods to mark an entity
> as being modified.
>
> I do not see this as a "contract-first" vs. "code-first" issue or
> distinction.
>
>
> Felipe Gaścho wrote:
> > sorry, I couldn't understand very well the scenario where your feature
> > can aggregate better value...
> >
> >
> >> "whether it has been modified since it was created or no"
> >>
> >
> > ok, it can be too much purism, but in my humble opinion JAXB is best
> > useful in case of contract-first development, and to suppose a
> > generated class can be modified is to assume you are
> > half-contract-first-half-code-first :(
> >
> > ok, if you are talking code-first only, perhaps it can be useful ..
> > but for contract-first does not make sense........
> >
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> > For additional commands, e-mail: users-help_at_jaxb.dev.java.net
> >
> >
>
>
> --
> Regards,
> Farrukh Najmi
>
> Web: http://www.wellfleetsoftware.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>