I am trying to use the TreeView available inside Forge but it seems complicates and the data list is based only on structures but not database data. So, I would like to know if there is some dynamic TreeView or hierarchical view component (based on database's records) that I can use for user role management?
There are several Tree components in the Forge, but I do not see one called "TreeView". Can you tell me which you are referring to? Also, I suggest posting on the Forge component's Support tab, which will probably get you more answers.
Related
I am looking for advice on how to use the QSYS2.DATA_AREA_INFO in a particular situation. So I have created a few views which selects data from multiple tables. I am trying to fetch data from a data area as well using the DATA_AREA_INFO function.
The views need to be installed in a number of data libraries. The create view SQL statement does not have any libraries hardcoded. The tables to pull data from will be based on the default library we set in iSeries navigator while creating the views. So once the view is created, it would permanently point to tables from the default data library set. (Hope this is correct?)
The issue is with fetching the data from the data area:
SELECT DATA_AREA_VALUE
FROM TABLE(QSYS2.DATA_AREA_INFO(
DATA_AREA_NAME => 'TESTDA1',
DATA_AREA_LIBRARY => '*LIBL'))
Writing the statement as above would result in the view selecting the data from the data area present in the library list.
But the jobs from which the views will be executed might not have a library list setup. Hence I cant rely on DATA_AREA_LIBRARY => '*LIBL'
Is there a way I can make the view point to the same data library always (same as how the tables work)?
You could wrap up the data area access in a (service)program which accesses the *dtaara via ILE. The advantage is, that your able to reuse the program in several ways, in and outside an sql context. You can find information about this technique here:
Scott Klement Powerpoint
Developing new C# .net4.5 Windows Forms application. I want to code it "right". I'm developing a couple User Controls. The controls are shared via several tabs. On the controls are some common drop down boxes that are populated with the same SQL Server table data. (one or two columns) I want to read the DB once and have the lookup data available during the entire user experience. The app will be used by many users. Whats the best way to store this data in my new code? example code appreciated. cache? static list ? Help! Thanks!
Simply a global DataTable (Dataset) would do. Or if you want control over the contents of the list using SortedDictionary containing your own custom class for each row would suffice.
The Custom Class is a tidy way of holding a cache (for the data you want from each row), as you can override the ToString function and populate the user controls easily.
To share this cache amongst many users is not easy, and could prove more trouble than its worth. Each user with a separate copy of the program would have their own copy of the cache (in the 2 methods above). (But the user controls will also contains subsets of this cache too). And each program would need to load the user controls, so perhaps this sharing across multiple instances direction is moot.
For application developers, I suppose the traditional paradigm for writing an application with domain objects that can be persisted to an underlying data store (SQL database for arguments sake), is to write the domain objects and then write (or generate) the table structure. There is a tight coupling between what the domain object looks like and what the structure of underlying data store looks like. So if you want to add a piece of information to your domain object, you add the field to your code and then add a column to the appropriate database table. All familiar?
This is all well and good for data stores that have a well defined structure (I'm mainly talking about SQL databases whereby the tables and columns are pre-defined and fixed), but now a number of alternatives to the ubiquitous SQL database exist and these often do not constrain the data in this way. For instance, MongoDB is a NoSQL database whereby you divide data into collections but aside from that there is no structuring of the data. You don't define new columns when you want to add a new field.
Now to the question: given the flexibility of a data store like MongoDB, how would one go about achieving a similar kind of flexibility in the domain objects that represent this data? So for instance if I'm using Spring and creating my own domain obejcts, when I add a "middleName" field to my data, how can I avoid having to add a "middleName" field to my domain object? I'm looking for some kind of mechanism/approach/framework to dynamically inspect the data and have access to it in my domain object without having to make a code change every time. All ideas welcome.
I think you have a couple of choices:
You can use a dynamic programming language and not have domain objects (clojure for example)
If you're fixed on using java, the mongo java driver returns data in DBObject which is essentially a Map. So the default behavior already provides what you want. It's only when you map the DBObject into domain objects, using a library like morphia (or spring-data), that you even have to worry about domain objects at all.
But, if I was using java, I would stick with the standard convention of domain objects mapped via morphia, because I think adding a field is a very minor inconvenience when compared against the benefits.
I think the question is inherintly paradoxical-
On one hand, you want to have domain objects, i.e. objects that represent the data (and behaviour) of your problem domain.
On the other hand, you say that you don't want your domain objects to be explicitly influenced by changes to the data.
But when you have objects that represent your problem domain, you want to do just that- to represent your problem domain.
So that if, for example, middle name is added, then your representation of the real-life 'User' entity should change to accomodate this change to the real-life user; perhaps not only by adding this piece of data to your object, but also adding some related behaviour (validation of middle name, or some functionality related to it).
In essense, what I'm trying to say here is that when you have (classic OO) domain objects, you may need to change your behaviour / functionality along with your data, and since you don't have any automatic way of changing your behaviour, the question of automatically changing your data becomes irrelevant.
If you don't want behaviour associated with your data, then you essentialy have DTOs, and #Kevin's answer is what you're looking for.
Honestly, it sounds more like you're looking for some kind of blackbox DTO where, like you describe, fields are added or removed "arbitrarily" depending on the data. This makes me inclined to suggest a simple Map to do the job. You can't really have a domain-driven design if your domain model is constantly changing.
I need to synchronize my Relational database(Oracle or Mysql) to CouchDb. Do anyone has any idea how its possible. if its possbile than how we can notify the CouchDb for any changes happened on the relational DB.
Thanks in advance.
First of all, you need to change the way you think about database modeling. Synchronizing to CouchDB is not just creating documents of all your tables, and pushing them to Couch.
I'm using CouchDB for a site in production, I'll describe what I did, maybe it will help you:
From the start, we have been using MySQL as our primary database. I had entities mapped out, including their relations. In an attempt to speed up the front-end I decided to use CouchDB as a content repository. The benefit was to have fully prepared documents, that contained all the relational data, so data could be fetched with much less overhead.
Because the documents can contain related entities - say a question document that contains all answers - I first decided what top-level entities I wanted to push to Couch. In my example, only questions would be pushed to Couch, and those documents would contain the answers, and possible some metadata, such as tags, user info, etc. When requesting a question on the frontend, I would only need to fetch one document to have all the information I need at that point.
Now for your second question: how to notify CouchDB of changes. In our case, all the changes in our data are done using a CMS. I have a single point in my code which all edit actions call. That's the place where I hooked in a function that persisted the object being saved to CouchDB. The function determines if this object needs persisting (ie: is it a top level entity), then creates a document of this object (think about some sort of toArray function), and fetches all its relations, recursively. The complete document is then pushed to CouchDB.
Now, in your case, the variables here may be completely different, but the basic idea is the same: figure out what documents you want saved, and how they look like. Then write a function that composes these documents and make sure this is called when changes are made to your relational database.
Notifying CouchDB of a change
CouchDB is very simple. Probably the easiest thing is directly updating an existing document. Two ways to implement this come to mind:
The easiest way is a normal CouchDB update: Fetch the current document by id; modify it; then send it back to Couch with HTTP PUT or POST.
If you have clear application-specific changes (e.g. "the views value was incremented") then writing an _update function seems prudent. Update function are very simple: they receive an HTTP query and a document; they modify the document; and then CouchDB stores the new version. You write update functions in Javascript and they run on the server. It is a great way to "compress" common actions into simpler (and fewer) HTTP queries.
I'm experimenting with Dancer some time, and looking for the right blocks to build my application. Frameworks tend to have flat example applications, dealing with one table at time. So I have no good idea which tools should be used to build a little bit more complex CRUD forms.
Let's say I create a Booklovers app. It should have a form to add/edit books with authors. To cover this I need 3 tables in our database: books, authors and books_to_authors. Which is best way to build a form to add a book with authors?
Note:
It is not known how many authors a book may have, we need dynamic adding of rows.
The authors table may have tens of thousands of records, so a select form element is not suitable.
An author may be missing from our database, we need to add them dynamically, too.
All these dynamic parts needs some AJAX. Is there a good solution to integrate it with form creating tools in Perl? I looked at CGI::FormBuilder and am still looking, but I did not find something that could build forms for 3 joined tables as described. The dynamic client-side part also still needs to be covered.
Are there some best practices for such a pretty simple case?
AJAX is for rendering data in a Web browser, it doesn't affect the back-end data storage.
The books and authors tables have a many-to-many relationship, using ORMs such as DBIx-Class can help.
In the Web form, there is a new book and a collection of authors. At the server side, create a book, then add authors to book.
Browse the DBIx::Class cookbook to get some ideas.
Sorry for not providing a simple answer to solve your problem.
Seems it is somehow too complex question to have straightforward solution.
I stick using templates forms and generete dynamic part with different jQuery plugins.
I don't think it is best way, but have not seen better for now.