I am using LLBL to generate ASP.NET forms for each entity. I would like to generate one form per entity per user role. In other words, there would be a CustomerEditOrder.ascx, a StaffEditOrder.ascx, an AdminEditOrder.ascx.

All of these can be derived from the same LPT file if I can just pass a prefix ("Customer", "Staff", "Admin") from the preset into the task performer, and then into the LPT as a global symbol.

My thought was to define a custom prefix in our <taskPreset> to achieve these results.

    <taskPreset name="SD.Tasks.Adapter.EntityBlocks.EditControlAscx">
      <parameters>
        <parameter name="destinationFolder" value="Controls" />
        <parameter name="prefix" value="Customer" />
      </parameters>
    </taskPreset>

1) DotNetTemplateEngine outputs file as [prefix]fileName.ascx

2) Symbol is passed into lpt so we can create classes named <%=prefix%><%currentEntity.Name%>

Is there any way to accomplish my goal?

have you checked out the ASP.Net 2.0 GUI templates? They are in Beta right now. I have read any complaints about the project so far. I downloaded the code and looked around, but haven't implemented it within any projects. Pretty slick for 100% generated code.

They do something similar to what your looking for. The system has an insert, edit, delete and search form. The forms load entity specific user controls based on which entity a user has selected.

These templates may point you in the right direction.

jmeckley wrote:

have you checked out the ASP.Net 2.0 GUI templates?

Ours are based on those but we ended up removing a lot because we don't want to use ObjectDataSource patterns.

I like the 2-way binding of ObjectDataSource, but not the persistence and validation. ObjectDataSource has two or three problems that I can't understand how to work around:

1) It handles persistence. This is a bad feature if you want persistence handled by a manager that does more than a simple update or insert. Unless you want to handle everything server-side with db triggers, you're stuck with pretty basic db operations if you use ObjectDataSources

2) I can't get an updated entity reference back from the data source

3) If there is a validation error or exception that doesn't become apparent until a Save(), your GridView/form is already out of Edit mode and you can't get back the data the user changed. It's client-side validation or nothing. (Am I wrong about this? Somebody please say I am and show with code)

So instead, we use a custom 2-way binding extension on web controls and our templates generate blocks of ASP.NET markup that binds to an entity but doesn't know anything about persistence.

1) It handles persistence. This is a bad feature if you want persistence handled by a manager that does more than a simple update or insert. Unless you want to handle everything server-side with db triggers, you're stuck with pretty basic db operations if you use ObjectDataSources

2) I can't get an updated entity reference back from the data source

3) If there is a validation error or exception that doesn't become apparent until a Save(), your GridView/form is already out of Edit mode and you can't get back the data the user changed. It's client-side validation or nothing. (Am I wrong about this? Somebody please say I am and show with code)

Using LLBLGenProDataSource: 1- You can handle database activities yourself by setting "LivePersistance = false". 2- And then you can get the updated entity refernce back from the saving method. 3- Would you explain more here?, other than client-side validation what exactly do you want to have?

The GUI templates use this scheme as well: in the filename you've to specify [elementName] to get the current element name in the filename. In the .lpt template, you obviously know the current element, so you can obtain the name from that object and thus emit it into the class, as I've done in the GUI templates.

Do you mean something else instead?

Walaa wrote:

Using LLBLGenProDataSource: 1- You can handle database activities yourself by setting "LivePersistance = false". 2- And then you can get the updated entity refernce back from the saving method. 3- Would you explain more here?, other than client-side validation what exactly do you want to have?

1. Good to know, will check!

2. Do you have a code sample of this? I hunted for the property but could not find it.

3. I mean that I think an ObjectDataSource has no way to bubble validation events back to the caller. For example, GridView in edit mode: if the persistence fails, when the user clicks Update, GridView returns to the normal view anyway. Am I wrong?

Otis wrote:

The GUI templates use this scheme as well: in the filename you've to specify [elementName] to get the current element name in the filename. In the .lpt template, you obviously know the current element, so you can obtain the name from that object and thus emit it into the class, as I've done in the GUI templates.

Do you mean something else instead?

This is a simplified example, but suppose I wanted to use your GUI templates to generate two copies per entity instead of just one. Instead of just [elementName], I would want [elementName]Copy1 and [elementName]Copy2. I want to somehow pass "Copy1" and "Copy2" into the lpt so it can add it to the class.

Ideally I would specify this in the preset, so it would become [elementName][suffix] where [suffix] is "Copy1" or "Copy2" depending on the parameter value I pass from the preset.

benles wrote:

Walaa wrote:

Using LLBLGenProDataSource: 1- You can handle database activities yourself by setting "LivePersistance = false". 2- And then you can get the updated entity refernce back from the saving method. 3- Would you explain more here?, other than client-side validation what exactly do you want to have?

1. Good to know, will check!

2. Do you have a code sample of this? I hunted for the property but could not find it.

You can with LivePersistence set to false, as you get the Unitofwork object passed into the event handler. So you can grab the entity there, save it and you have a reference.

This isn't very intuitive, so we'll add better ways to obtain a new entity through events in v2.1

1. I mean that I think an ObjectDataSource has no way to bubble validation events back to the caller. For example, GridView in edit mode: if the persistence fails, when the user clicks Update, GridView returns to the normal view anyway. Am I wrong?

I think you're right, simply because asp.net has no facility build in to act on errors, you have to implement that yourself.

benles wrote:

Otis wrote:

The GUI templates use this scheme as well: in the filename you've to specify [elementName] to get the current element name in the filename. In the .lpt template, you obviously know the current element, so you can obtain the name from that object and thus emit it into the class, as I've done in the GUI templates.

Do you mean something else instead?

This is a simplified example, but suppose I wanted to use your GUI templates to generate two copies per entity instead of just one. Instead of just [elementName], I would want [elementName]Copy1 and [elementName]Copy2. I want to somehow pass "Copy1" and "Copy2" into the lpt so it can add it to the class.

Ideally I would specify this in the preset, so it would become [elementName][suffix] where [suffix] is "Copy1" or "Copy2" depending on the parameter value I pass from the preset.

At the moment that's not how templates work. You should see a template as a template for a file. So if you want 2 files, you have to execute 2 tasks which thus generate a file each.

It's now a pretty simple process: all entities get passed into the task performer, the task performer checks what the emit type is, and either generates one file (generic) or one file per element, and there's no logic possible where you can select a subset per task for example.

Is it solvable that you add 2 tasks, which both generate a copy? e.g. the first generates copy1 and the other generates copy2, or will you then get too many files? (I.e. also the files for entities you didn't want to be used by that particular task.)

I will probably need this selection process for v2.1, so I will come up with something though at the moment it's straightforward.