On Tue, Jun 10, 2008 at 12:07 PM, Paul Were <[EMAIL PROTECTED]> wrote: > Matt, > in reference to the issue here it's especially helpful if the hooks for > customization were provided such that upgrade path on future version of > appfuse might not be as complicated for those who would like to customize > heavily but leave options open for easy upgrades. > > e.g. the current User class would be extended by a Custom user class > provided out of the box within appfuse. i.e. most of the implemented appfuse > classes could provide these shell class extensions for entry point into > customization. > -the CustomUser class would be an empty shell and an entry point for > customization. > -The custom user class and related shell custom classes would be the base > references in the configuration files for out of the box AppFuse. > -As such any further appfuse implementation would always be done in the > super classes and would not conflict with any specific implementation if > done right meaning virtually no conflict with user specific customization if > one upgrades to a newer version of AppFuse. > -If managed right I could simply full-source future version of appfuse into > my development environment with my customization build without risking > overlaying my customization or changing my configuration files. > -This would probably go a long way in alleviating some of the problems that > would face people who would like to customize heavily but would still like > to upgrade to future version of appfuse. > -Also as a caveat these custom classes would also be a link back into future > functionality that could be provided out of the box, if it seems that it's > common across many implementations and maybe more derivatives would follow > from there. > > Just a thought and if you need someone to tackle it i could.
We're always open to contributions. The only thing I wouldn't want to do is make it too complicated for beginners to understand. It might be nice to remove all functionality and move code to plugins that could be customized and versioned on their own. Matt > > Paul > > --- On Mon, 6/9/08, Matt Raible <[EMAIL PROTECTED]> wrote: > > From: Matt Raible <[EMAIL PROTECTED]> > Subject: Re: [appfuse-user] UserDao in the way on spring security > To: [email protected] > Date: Monday, June 9, 2008, 9:26 PM > > I believe the easiest solution is to import the core classes into your > project and customize them there. > > http://appfuse.org/display/APF/AppFuse+Core+Classes > > If that doesn't work for you, full-source your project and customize > to your heart's content. > > Matt > > On Sun, Jun 1, 2008 at 3:45 PM, mschipperheyn <[EMAIL PROTECTED]> > wrote: >> >> Hi, >> >> I have an implementation with an independent user object. I > basically > don't >> use the Appfuse User and Role model. In the process of migration I ran > into >> a problem with my custom UserDetails service. Using the default >> implementation I get a "More than one UserDetailsService registered. > Please >> use a specific Id in your configuration". I'm sure I can work > around this at >> the sacrifice of the short xml configuration. >> >> I would like to suggest to move the User and Role classes and associated >> generated code to the implementation directories of the generated >> application as opposed to storing them in the appfuse jars. This gives > more >> flexibility for users who don't want to do a full source but just > don't want >> the out of the box pojo's and the limitations that come with them: >> * not being able to use bean ids like user, userManager for your own user >> beans >> * loadUserDetails > conflicts. >> >> It also feels like a more natural separation of concerns. >> >> Kind regards, >> >> Marc >> -- >> View this message in context: > http://www.nabble.com/UserDao-in-the-way-on-spring-security-tp17590739s2369p17590739.html >> Sent from the AppFuse - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
