I'm trying to build a custom HTML helper for MVC.NET that would allow me to render object entities (Model Objects) as HTML forms. So I decided to do it using custom attributes such as html input type, readonly flag, css classes, etc. Similar in a way to LINQ Mapping attributes that set database related bindings for Table and Column. So I did write a custom attribute class, applied it to the same entities that I store in the database, but when I retrieve an entity class from a database to display in a View, all of my custom attributes are gone. Is there a way to retain my custom attributes, AFTER they come back from a database?
Related
I noticed that graph.Caches[typeof(MyDac)] is quite useful in Acumatica to manipulate values in other DACs. What would be the proper way to use it, for example when I update a value in another DAC? Do I have to persist right after it, or will it be saved to DB when I run graph.Action.PressSave(), even if I am not using this DAC in any of the view in the graph?
The PXGraph.Caches collections contains DAC objects loaded in memory on the server. In a graph it is accessed directly as this.Caches and in an extension it is accessed through Base.Caches. While not technically acurate it can be thought of as a global DAC cache. The DAC objects contained in DataView.Cache is a subset of the DAC objects in PXGraph.Caches.
The usual pattern for persisting records is by using graph DataViews. The PXGraph.Action.PressSave() will persist the records when the current record of the primary DataView of the graph is properly set.
The primary DataView of the graph is declared in the ASPX PrimaryView property of the PXDataSource element:
<px:PXDataSource ID="ds" runat="server" PrimaryView="Document" TypeName="PX.Objects.SO.SOOrderEntry" >
Setting PrimaryView.Current record in the BLC graph is required for the Save action to persist the DataViews records.
It is also possible to persist DAC objects in DataViews without invoking the Save action. To do so you would perform a CRUD operation and then Persist the DAC objects in the DataView using:
DataView.Insert(DAC)
DataView.Update(DAC)
DataView.Delete(DAC)
DataView.Cache.Persist(PXDBOperation.Insert)
DataView.Cache.Persist(PXDBOperation.Update)
DataView.Cache.Persist(PXDBOperation.Delete)
While it is possible to do the same operations on PXGraph.Caches there are few situation where this is required in user code because using DataView is the preferred method of persisting DAC objects and access to DataViews is available when you have the BLC.
Where PXGraph.Caches is especially useful is when working with PXGraph instead of a BLC, often found in the context of generic code. You can access DataViews of the BLC like SOOrderEntry.Document with a reference pointing to the SOOrderEntry BLC. However if all you got is a reference to the PXGraph base class of the BLC you don't have access to the DataViews. In that case you can still access the DAC objects in PXGraph.Caches. By knowing the type of the DataView DAC objects for example SOOrderEntry.Document is of SOOrder type and will be in PXGraph.Caches[typeof(SOOrder)]. For user code this pattern is more common in custom attributes that have access to the PXGraph object but not the BLC. In BLC it's more common to work on the DataView.Cache instead of PXGraph.Cache.
Another possible scenario where accessing PXGraph.Caches could be useful is when you have many DataViews of the same type. If you want to query all updated DAC objects of a same type that are in multiple DataViews you can itereate on Caches[typeof(DAC)].Updated. It's also quite common to simply fetch a reference to a Cache object using Caches[typeof(DAC)] that will then be passed to another Acumatica framework method by input parameter. In this case it's often a matter of convenience because the same Cache reference could be obtain through DataView.Cache.
I have created a custom content type (via the admin UI) that consists mostly of text fields. I know how to position the fields using zones and Placement.info but for simplicity I would like to use a single view template and to just arrange the fields by name instead of having to use Placement.info. Is there a good way to reference the fields by name from the content item in my MVC view?
So for example, I have a template named Content-MyContentType-Detail.cshtml. Instead of the generic
#Display(Model.Content)
I would like to be able to do something like
#Display(...MyField...)
#Display(...MyOtherField...)
Is there a way to explicitly render a field by name that is associated with my content item?
You can use Shape Tracing module to view model properties and how to get access to content parts.
Then in your template you can use something like this:
<h3>#Model.ContentItem.TitlePart.Title - £#Model.ContentItem.Product.Fields[1].Value</h3>
<p>#Model.ContentItem.BodyPart.Text</p>
If you don't just want to access the field's properties, but rather would like its shape rendered in-place, but like it would be when using placement (i.e. using the existing template), then read this article, which describes how to do direct rendering without placement: http://weblogs.asp.net/bleroy/archive/2013/02/13/easy-content-templates-for-orchard-take-2.aspx
I am trying to reverse engineer a SQL Server database to an Entity Framework Data Model (version 6.0). The classes are generated fine, but required fields are not decorated as such. As a result the validation is not working (in an MVC 5 web application).
Is there a way to make the model generate these attributes automatically or do I have to manually write meta data classes for all my entities?
Speaking to your question, What are your assumptions for required fields? Do you mean non-nullable?
EF should make any field that is marked as not null as either a non-nullable value type (int, decimal, bool, etc.) or it will make fields required via xml validation. EF doesn't typically add attributes.
MVC will automatically make any value types required, no attribute is required. For strings or other possible nullable types, then you will either need "buddy classes" to add the attributes you need, or you use view models.
I'd like to place some custom methods directly into each NSManagedObject. Think, "calculated fields": these methods provide read-only calculated values based upon persistent values on the Entity - which is identical to this question.
I'm using the Xcode New File... Wizard to create NSManagedObject subclasses for each of my Entities. I'm trying to benefit from the system auto-creating the accessors for me. For example:
Core Data Entity: "Site"
#interface Site : NSManagedObject
As I continue to add new Attributes to my Entities, I'm replacing their corresponding NSManagedObjects by using the Wizard. When each file is replaced, my custom methods are lost.
Should I create my custom methods elsewhere so that I can continue to leverage the Wizard? Or, should I keep the methods on the NSManagedObject and add Accessors for new Attributes manually? Is there another approach?
Create a category on your NSManagedObject subclass:
In the "New File ..." dialog, choose "Objective-C category".
Create a category "CustomMethods" on "Site".
Xcode will create files Site+CustomMethods.h, declaring the #interface Site (CustomMethods), and Site+CustomMethods.m for the corresponding implementation.
Add your custom methods to the category.
These files will not be overwritten when you recreate Site.m and Site.h in Xcode.
All category methods can be used as if they had been declared in the class itself. The only thing you can not do in a category is add new instance variables.
Once I have used the wizard to create the initial managed objects, I generally change them manually.
Another way of doing this is to create subclasses of the wizard generated class files and use these.
When they are regenerated, all of your custom code is in the subclass, as opposed to the overwritten class file.
we're using Automapper (http://automapper.codeplex.com/) to map between entities and dto's. We have a situation where one property on an entity corresponds to three different properties on the dto, and we need to write some custom logic to do the mapping. Anyone know how we can do that? (We need to map both ways, from entity and from dto).
I notice that AutoMapper supports custom resolvers to do custom mapping logic, but as far as I can tell from the documentation, they only allow you to map a single property to another single property.
Thx
You can create a custom type converter. It allows you to define a converter for an entire type, not just a single property.