I have a complex entity which is displayed in tables in different places. In one place I want to show a subset of properties only. For this projection I made a special in-memory object, which wraps the complex entity and has getters for the subset of properties only. How can I mark this inmemory object to be not openable?
as per the Apache Isis mailing list, can use the #cssClass() UI hint coupled with some custom CSS and Javascript.
Related
I want to have two classes that are independent of each other. A content type and a URL. A URL will have a conent type.
Could I add into the content type a summary field, which could be easily queried (e.g content type X has 10 URL's) or would I need to query all of the URL's and pull out the content type that way?
A URL can also be associated with other classes (not just this content type), which is why I don't create a superclass of content type, and then a sub URL class.
That depends. Basically what you are asking is the following: Given a 1:n relationship, how can I automatically query both directions?
If you use a database to store your data, most object-relational mappers give you this functionality for free. If you don't, you need to handle it yourself.
There are various options. The most simplistic approach is to iterate all URLs and filter the ones that match the queried content type. This is most likely the responsibility of some container. This variant is very easy to implement but takes O(number of URLs) time to execute the query. So if you just have a few URLs, this may be the way to go.
The other option is to explicitly store the inverse relationship. Either directly in the content types or in a container (e.g. within a hash map). The main problem of this approach is keeping both pairs of a relationship in sync. You could use the setter of the URL's content type property to update the content type's URLs property. The task of synchronizing the relationships could also be handed over to a container. Anyway, this option is significantly faster but requires some programming effort. Depending on your concrete scenario, this might be more or less work.
I am getting NullPointerException when accessing member fields only 3 levels deep in my view template:
#tfz.modelTfzTyp.simulierteTfzTyp.typ
If I use getter functions instead, it works. But it is cumbersome.
I am using Ebean and I read that Hibernate has a max_fetch_depth. I am suspecting that something similar is causing my problems. How do I make Play load more objects eagerly?
This has nothing to do with the max_fetch_depth property.
Dynamic fetching is allowed by byte code enhancement on the models, and it works only for the getters.
See the official documentation:
Enhancement of direct Ebean field access (enabling lazy loading) is only applied to Java classes, not to Scala. Thus, direct field access from Scala source files (including standard Play 2 templates) does not invoke lazy loading, often resulting in empty (unpopulated) entity fields. To ensure the fields get populated, either (a) manually create getter/setters and call them instead, or (b) ensure the entity is fully populated before accessing the fields.
We are using Lucene as the search server for data retrieval.
With this come certain complexities that I was unprepared for, not the least of which is managing relationships between objects.
I want to create a clean and simple POCO for our domain objects. These POCOs will contain related objects that I need for the UI, but no other fields (IDs defining these relationships, various other fields I simply don't need on the UI)
This means that I cannot directly translate Lucene's Hits collection into my UI-friendly POCOs and need some intermediary set of classes that will, at the least, contain IDs of related objects (stored in the same, or other indeces). I hesitate to call these DTO objects but for the sake simplicity I will call them that.
So I envision it working as follows:
Perform query in Lucene -> Hits collection
Iterate through Hits -> DTO collection
DTO collection -> [service to retrieve related objects, compose a POCO] ->
POCOs
Render a UI using the shiny simple POCOs
My fear in doing so is that I'll end up with Anemic Domain Model ( http://www.martinfowler.com/bliki/AnemicDomainModel.html ).
Is this a valid concern or am I on the right path?
I've ended up going the familiar to me pattern of a DTO. DTO has all the IDs - it is merely a CLR reflection of a record retrieved from Lucene.
I then map from DTO to a POCO in the service layer and use those objects to render the UI elements.
Does not feel slick, but it works.
Without any ID information in your POCOs, your design will likely suffer from anemia as there will just be an unconnected jumble of objects (which may not even fit all in memory at once). Also, it would seem to me that the lack of IDs would greatly interfere with caching and memoization (which help in not hitting the database every time you need an object). I have rarely had the luxury of assuming that all of my data will fit in memory all at once.
I'm writing an application to help diabetics manage their condition. Information that is tracked includes blood sugar results, nutrition, exercise, and medication information.
In similar applications these entries are all presented in a single table view even though each type of entry has different fields. This data is manually tracked by many diabetics in a logbook, and I'm looking to keep that paradigm.
Each entry has some common information (timestamp, category, and notes) as well as information specific to each entry type. For instance, meal entries would have detailed nutrition information (carb counts, fiber, fat, etc), medication entries would indicate which medication and dosage, etc.
I've considered two different approaches but I'm getting stuck at both a conceptual level and a technical level when attempting to implement either. The first approach was to create an abstract entity to contain all the common fields and then create entities for each log entry type (meals, meds, bg, etc.) that are parented to the abstract entity. I had this all modeled out but couldn't quite figure out how to bind these items to an array controller to have them show up in a single table view.
The second approach is to have one entity that contains the common fields, and then model the specific entry types as separate entities that have a relationship back to the common record (sort of like a decorator pattern). This was somewhat easier to build the UI for (at least for the common field entity), but I come to the same problem when wanting to bind the specific data entities.
Of course the easiest approach is to just throw all the fields from each different entry type into one entity but that goes against all my sensibilities. And it seems I would still run into a similar problem when I go to bind things to the table view.
My end goal is to provide an interface to the user that shows each entry in chronological order in a unified interface instead of having to keep a separate list of each entry type. I'm fine with adding code where needed, but I'd like to use the bindings as much as possible.
Thanks in advance for any advice.
Don't get bogged down with entity inheritance. You shouldn't use it save duplicate attributes like you would with classes. It's major use is allow different entities to be in the same relationship. Also, entity inheritance and class inheritance don't have to overlap. You can have a class inheritance hierarchy without an entity inheritance hierarchy.
I'm not sure I understand exactly what you really need but here's some generic advice: You shouldn't create your data model based on the needs of the UI. The data model is really a simulation of the real-world objects, events or conditions that your app deals with. You should create your data model first and foremost to accurately simulate the data. Ideally, you should create a data model that could be used with any UI e.g. command-line, GUI, web page etc.
Once your model is accurately setup, then whipping up the UI is usually easy.
I'm not quite sure of the most elegant solution for what I am trying to do.
I have a page which lists music listings, there can be thousands of these so they are paged in batches of 20, I also have 4 links at the top of the page to change the way these listings are ordered.
The sort by properties could be located on different entities such as Audio.AudioStats.NumComments or Audio.Artist.NumProfileViews.
I am using the repository pattern, and a service layer. My controllers can only access the service layer, then the service layer accesses my repositories.
I can do the paging fairly easily, i simply pass in my current page, and the page size to my data layer...but how would i safely let the user decide on the ordering of my entities.
I am using S#arp Architecture 1.5.2 if that makes any difference.
Thank you in advance.
You are going to have to map the users' desires to an order by clause somehow.
Presumably you're doing something like skip(n).take(m) which will need an orderby() clause too.
Given that you have a fixed set of (known) possibilities, you can map those to an enum or similar which you then translate to the relevant orderby() call.
This means you don't expose the properties at the UI layer but only pass through the intent to the repository layer (as a Sortby.ArtistProfileViews value or whatever). What how that intent is mapped to the properties on you domain objects is isolated in your repository layer.