1. Should I pretend the future changes do not exist and simply map the
stuff I need right now, knowing I will need to write something that can
migrate the data later, or should I create the ContentArea DO now and
just expand on it later and not have to do a migration at all (leaning
this way)?
2. How should I map the next version items anyway (tables do not exist
yet)? Am I thinking about the problem right?
Right now I have a need for a domain object like the following
(background at end):
public class BasicContentAreaModuleInfo {
public int Id { get; set; } //FK to table that isn't mapped,
//known at all times by code
public int Tab { get; set; } //user determined (id of the "tab"
[page] where the content is located)
public string Pane { get; set; } //user determined (name of the
"pane" containing the items in the tab)
}
However, the pair Tab and Pane together identify an item that eventually
will stand as its own domain object:
public class ContentArea {
public Guid Id { get; set; }
public int Tab { get; set; }
public string Pane { get; set; }
//will need future version (phase 2 deliverable)
public string Name { get; set; } // to allow people to specify
names for these
// and search for them
public string Title { get; set; } // default title for use when
displaying
}
Which I could just as well use right now:
public class BasicContentAreaModuleInfo {
public int Id { get; set; }
public ContentArea ContentArea { get; set; }
}
And in the next version:
public class TitledContentArea {
public ContentArea ContentArea { get; set; }
public string Title { get; set; } // title override for display
if set
}
public class TitledContentAreaModuleInfo {
public int Id { get; set; }
public TitledContentArea ContentArea { get; set; }
}
public class TabbedContentAreaModuleInfo {
public int Id { get; set; }
public IList<TitledContentArea> Tabs { get; set; }
//will have other options here like CanWrap, LoadOnDemand, etc.
}
I haven't had a need to use a domain object as part of multiple mappings
before (the whole schema I am using AR for is one where every domain
object is referenced by at most one other)
In sql I would probably make tables something like this (skipping on sql
syntax):
BasicContentAreaModuleInfos(
ModuleId int, --PK, FK to modules
ContentAreaId uniqueidentifier --FK to ContentAreas
)
ContentAreas(
Id uniqueidentifier, --PK
TabId int,
PaneName nvarchar(max),
SearchName nvarchar(max), -- unique constraint (could default to
be the same as the id for the moment)
Title nvarchar(max)
)
TitledContentAreaModuleInfos(
ModuleId int, --PK, FK to modules
ContentAreaId uniqueidentifier, --FK to ContentAreas
Title nvarchar(max)
)
TabbedContentAreaModuleInfos(
ModuleId int, --PK, FK to modules
... other info here for this object (not necessary for this
discussion)
)
ContentAreaModuleTabs(
Id uniqueidentifier, --PK
ModuleId int, --FK to TabbedContentAreaModuleInfos
Title nvarchar(max),
ContentAreaId uniqueidentifier, --FK to ContentAreas
SortLocation int
)
----------
Background:
There exists named Panes located on Tabs in our site (DotNetNuke if you
must know). These Panes contain modules. In the immediate version, I am
to create a module which loads all the modules in the identified Content
Area (pair containing Pane and Tab) inside of itself. After this version
is finished and the concept is demonstrated I am to create 4 more modules:
1. a module that provides a way to name particular known content areas
to ease their reuse and give them default titles
2. a module that displays a content area inside of a fieldset with a
particular label (title)
3. a module that displays a content area inside of an ajax based in page
"window" (likely a Telerik RadWindow or a jquery one)
4. a module that displays a list of content areas as part of a tab panel
in a specified order
These new modules (and the original) must be able to be configured with
what content area is being displayed by a dropdown like mechanism that
allows you to search/select a known content area (ambiguities are why
these items are separate deliverables, we are currently providing
mockups for the UI in question covering various options). In the
meantime the client will be using the basic module in various locations
and will configure the names and titles of these areas at a later time.
--
You received this message because you are subscribed to the Google Groups "Castle
Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
