Web DB Editor templates for ASP.NET webforms (C#), Adapter.
======================================================
First released on: 10-jun-2008
Updated to v3.5: 19-mar-2012
Updated to v4.0: 22-apr-2013

Version: 1.2. final
	   
KNOWN ISSUES
=============
- In EditExisting, the required field validators for DateTextBox controls aren't called by ASP.NET (always valid). 
  It's unclear why this happens. This results in a form which will be 'accepted' even if the date is invalid/not 
  filled in. 


IMPORTANT
=========
These templates are a proof of concept and should be used as an example how to generate
UI's. To customize and extend the code generated, you should first look into extending the templates
or use them as a base for your own templates. The generated UI is fully functional though, and designed
to be scalable even with very large projects, though with very large projects and very large databases,
(i.e. millions of rows in a table) it's key to pay attention to the custom property directives to 
control what the templates generate. 

The templates are for adapter and will generate C# code. To port these templates to SelfServicing, you
should focus on the data-access code in the code behind templates (suffixed with 'Code') first. 


REQUIREMENTS
=============
- LLBLGen Pro v4.x

Supported features
===================
- Entity insert/edit/delete/view.
- viewing of related entities
- Fields mapped onto related fields
- Image/blob fields (insert / edit only)
- filtering and searching. 
- sorting (client side sorting when fields mapped onto related fields are used)
- pre-selecting of FK values when adding new entities.
- Automatic paging
- much more.


Installation
=============
Unpack the archive in the LLBLGen Pro installation folder as administrator, it already has the correct folders setup in the archive. 
You can also unpack it into a different folder and specify the 'Tasks' folder in the archive as the additional tasks folder and
the 'Templates' folder in the archive as the additional templates folder in the preferences or project properties. 

Alternative installation:
---------------------------
You can also install the templates in its own folder on disk. In your LLBLGen Pro project's settings, please set the 'Additional Tasks Folder'
to the Tasks folder in the DbEditor archive and the 'Additional Templates Folder' to the Templates folder in the DbEditor archive, and re-load
your LLBLGen Pro project or click Tools -> Refresh code generation meta-data.


Usage
======
(With 'DAL' the normally produced generated code is meant, i.e. the 'Data Access Layer' LLBLGen Pro generates for you
with the normal adapter presets or selfservicing presets)
These templates come with their own presets, SD.Presets.Adapter.WebDbEditor and SD.Presets.SelfServicing.WebDbEditor, 
and works with the DAL code generated by the presets SD.Presets.Adapter.General or
SD.Presets.SelfServicing.*.
The WebDbEditor preset will generate a GUI folder with code for you, which utilizes the generated DAL code. The preset 
won't generate a .sln file for you, you have to do that yourself within VS.NET. The code in the GUI folder is compatible 
with the VS.NET 2008/2010/2012 web site project on disk, which means there's initially no csproj file. Keep the same rootnamespace for 
the GUI generation action as you did use for the DAL generation action. You can combine the two presets to one single preset
to generate DAL code and GUI code in 1 generation action. To do that, use the Merge preset button in tab 3 on the 
generator configuration dialog. See the LLBLGen Pro manual for more details about merging presets. 

There's no middle 'BL' tier in the generated web db editor, all data-access logic is in the code behind classes. The GUI folder 
is a default web site project, so you can create a new web site project within VS.NET from the GUI folder, then reference the 
DAL vs.net projects and of course setup a virtual directory on your webserver to run the website. You don't need to reference the
ORMSupportClasses in the GUI/website project, as the adapter projects already reference this assembly.

The web.config file will contain the connection string as known in the LLBLGen Pro project. Once generated, 
the web.config file won't be overwritten, so you can alter it to something else and re-generate the code if you want to. 

If you need name overwriting for schema/catalog, you should uncomment the sections in the web.config preserved for that
and add the necessary elements as described in the LLBLGen Pro manual.


Custom Property Directives
============================
You can control what the templates generate by adding custom properties to the entities, entity fields etc.
The function of these custom properties is described below. Custom properties are case sensitive, so specify
the custom property keys with the same casing. To bulk-set custom properties, for example with data from a file, 
consider the sourcecode of the custom property plug-in and modify it to your own liking so you can bulk-set
custom properties in one go.

Field label texts:
-------------------
Applied to: Entity field, add custom property to Entity field. 
Key: LabelText
Value: the text the label in front of the field data holding control / column has to have. 

Entity string representation fields:
-------------------------------------
Applied to: Entity, add custom property to entity
Key: DescriptiveField
Value: the exact field / property name of the field / property which returns at runtime the descriptive value for the 
	   entity. This value is used in combo-boxes to fill FK fields (e.g. CompanyName is a good candidate for the Customer
	   entity). If an entity doesn't have a descriptive field, or you want to combine a couple of fields (e.g. first name
	   and lastname), you have to add a partial class to the particular entity, add the property there, and specify the
	   property name as DescriptiveField in the entity's custom properties in the LLBLGen Pro designer. This is a restriction
	   of .NET databinding which can bind to a single field only. 
Note: If there's no DescriptiveField specified on an entity, the first PK field found is used.
	   
Lookup combo-boxes for FK fields:
----------------------------------
Applied to: Entity field, add custom property to entity field. Single field FK's only, only m:1 and 1:1 relations supported.
Key: UseLookupDropDownList
Value: not used (can be left empty)
Note: This is only supported on single-field FK's. The combo-box will be created with a datasourcecontrol and filled separately
      The related entity's DescriptiveField is used as datatextfield. Only add this custom property to fk fields which point to 
      a set of entities which isn't too big, otherwise you run the risk of pulling thousands of entities into memory to fill the
      dropdownlist. 
	  

CHANGELOG
==========
22-apr-2013:
CHANGED: Ported to v4.0 of LLBLGen Pro

19-mar-2012:
CHANGED: Ported to v3.5 of LLBLGen Pro

1-sep-2010:
ADDED: Ported to SelfServicing as well.

17-jul-2010:
CHANGED: Ported to v3.0 of LLBLGen Pro

10-jun-2008:
CHANGED: Ported to v2.6 of LLBLGen Pro

14-jun-2007:
CHANGED: Ported to v2.5 of LLBLGen Pro.
FIXED: When two or more relations were present to the same entity, the generated 
	   datasourcecontrols in the edit / insert templates in the entity edit control 
	   had the same ID.
FIXED: Regex problem in format string in generalutils.lpt for Int64 fields: the regex 
	   specification matched a string.Format fragment.
ADDED: Preset which combines Adapter general 2005 preset and DbEditor preset so just 1 
       preset has to be used to generate both DAL and GUI
CHANGED: Switched off validation of request in the Page element of AddNew.aspx, EditExisting.aspx 
       and ListSubset.aspx to allow Xml and other texts to be specified without getting a server error. 
FIXED: When a DateTime field was part of the PK, the Search control wasn't properly generated: 
	   the code behind referred to a textbox control while a datetime field is generated 
	   as a DateTextBox. 
FIXED: TextArea controls which were mandatory, weren't shown with a themed different background color.
FIXED: Mandatory DateTime fields weren't validatable, because the DateTextBox control lacked a proper validator property.
FIXED: In the search form for subset search, a non-nullable datetime field were shown as datetextboxes with the  
	   background color for required fields, and the field itself was marked as required as well. 
FIXED: GUID pk's weren't usable in a search (for example for 'Edit Existing'), as the code behind file for the 
	   search control has incorrect code for converting the string to a normal GUID. Also added: code to make the code
	   compilable for entities with a PK which is a byte[]. 
FIXED: Entities without a PK still got edit/delete functionality generated which was leading to non-compilable code or
       a badly functioning application.
FIXED: If a subset of the entities in the project is used to generate the code, the templates were still referring to all
       entities in the project, instead of using the selected subset. 