Plug-ins Questions
Joined: 07-Aug-2006
renesisx wrote:
OK, I'm almost ready to buy, but there are two things I'd like to know.
The first and most critical is:
- Would it be possible for me to use the plugin SDK to write a plugin that renames all the field names on the entities?
LLBLGen forces its "first letter must be caps" rule onto us which is useless for our design. I know what FxCop says. I know what Microsoft's Best Practices are. They're not how our company works. Can I write a plug-in that will fix all the field names? I'm not willing to pay a developer to sit there for a whole day renaming fields.
Yes, though I'd not use such a thing on .NET. Don't get me wrong, you should use what you want to use, but in general, it's best to adapt the naming schemes used the most on the target platform. Which thus means camel cased method/property/field names in java and Pascal cased method/property/field names in .NET. Sooner or later you'll regret it.
Second question:
- Would the plug-in SDK allow me to extract a custom field property from the DB (e.g. "Description") and add it as an in-line XML "summary" comment above the field name in the Entity? This would allow us to "comment" our field names in only one place and have it appear magically in the intellisense, which would be rather lovely.
This is already the case. Custom properties added to a field will end up in the summary XML comments of the field property in the entity class. 
Joined: 07-Aug-2006
Joined: 07-Aug-2006
renesisx wrote:
Otis wrote:
Yes, though I'd not use such a thing on .NET. Don't get me wrong, you should use what you want to use, but in general, it's best to adapt the naming schemes used the most on the target platform. Which thus means camel cased method/property/field names in java and Pascal cased method/property/field names in .NET. Sooner or later you'll regret it.
Oh, I'm with you. The problem I have is that you guys have known about this limitation in LLBLGen for a long time and have conciously chosen to force your ideology onto your customers. You're making presumptions about how your users will want to use your product.
Well, why would we spend time on a feature no-one would use (ok, a small group 
) ? We also don't offer the option to generate code in hungarian coding style for example.
I didn't design this customer's database or existing code, but I do need to work to their style, and the lack of a simple checkbox to keep the field names identical to the DB field names (where possible) is a big limitation.
No it's not, as it's very rare that someone would want to use camelcased field/property names. And if s/he wants to, a plugin is a 'solution' to that rare circumstance. Though you have to run it every time, but it's your choice to opt for a rare naming scheme.
Added to that: MS gives our their .NET code with solely pascal cased methods and properties.
What I do in private with my code is my choice. You can advise me that I'm making a bad decision - feel free to bring up a big red flashing warning box when I choose a path you disagree with, but still give me the freedom to make that decision. That is all I ask.
If you want to, you can write a small plugin which traverses the fields etc. But we can't nor will add features for every naming scheme on the planet, as that's simply undoable. We chose to commit to the MS guidelines, and that's what we'll keep on doing.
The two options aren't effecting the first character of the name, which is always uppercased.
Joined: 10-Mar-2006