Does anyone know of any work around of "Retraining" models in Form Recognizer APIs? I understand that Form Recognizer Training APIs create a New model everytime you train a data set. Did some manage to have a workaround to continuously training models?
There is not such workaround. You may delete the old models if you are concerned about number of models grows too fast.
Or do you have other reasons trying to keep using the old model ID?
Related
Best wishes to all helpers!
I searched hard but nobody could give answer about pagination for tables in qooxdoo. It is fantastic framework but why developers (and architectors) missed that not so deep and hard feature built in?
Thanks to anyone who will answer!
Oleg
the qooxdoo table (lets hope you speak of the qx.Desktop layer) is a virtual widget and can handle a huge set of data without suffering any kind of performance decrease. Knowing that, there has been no need to add pagination to the table. If you don't want to load all the data at once, you can use the Remote Table Model to fetch only visible data. You can also check out the demo of this model to get an Idea of hot it is used.
I came across a few projects where AngularJS is used along with Sencha Touch (for e.g. https://github.com/tigbro/sencha-touch-angular-adapter). Is there a benefit to using both together? If so, for what? I was under the impression that both of them are full fledged frameworks and you wouldn't have to mix/match.
IMHO, it is not worth the trouble.
Actually, it is very easy to mix other frameworks/libraries into SenchaTouch/ExtJS, and (I assume) people's motivation of doing that is mainly to get the benefit of two-way data binding into ST/Ext.
Things will be fine if you just touch the surface. Your HTML becomes clean and more maintainable, no more "weird" <tpl> tags floating around inside your JavaScript code, etc. The UI part of your project becomes beautiful.
And, you can even easily make data binding sync with simple Ext.data.Model flawlessly.
However, if you're using ST/Ext to handle data communication with backend, you're dealing with Ext.data.Store most of the time. Your collection of data come back from backend into the stores, and your models' hasMany associations are in the form of stores, just to name a few.
Now, how to sync stores with the plain JavaScript arrays or some kind of observable arrays which are used in two-way data binding? What need to be done to stores if the bound arrays changed? What need to be done to bound arrays if stores changed? Adding, removing and inserting are fairly simple operations to deal with, how about sorting and filtering?
Therefore, if you can afford to give up Ext.data.Store, mixing angular with ST/Ext is fairly easy task; otherwise, just stick with sencha.
we are currently building our first large application with Silverlight 4 (using PRISM) and Entity Framework 4. Now I'm having a general question about persisting view model data.
Suppose I have domain objects which translate to EF4 entities with multiple associations (Entity having collections, having collections again etc..). What would be the best way to persist those graphs during / after user actions? Would it be better to write more granular repository methods like "AddEntityToParent" and "RemoveEntityFromParent" or just take all the data from the view and push it to a "SaveLargeParentEntity" Method?
Can I "cache" the view model items for child objects in Silverlight and push it all down to EF4 later or would I have to make a granular update for every single item changed in the user interface? Any good advise? I hope my question was clear enough. Thank you.
You are actually making a choice between basic CRUD operations and working with object graphs. I would choose second approach because CRUD operations over web service can be very chatty.
When working with object graphs send over web service you have to deal with detached behavior. Detached entities + object graph couses some troubles when updating relations. The best approach usually is to load the whole graph before update (get attached entities) and merge received graph into attached one - it will correctly track changes for you.
But because you are using Silverlight which is stateful you can also think about using Self tracking entities (STE). STEs are able to track changes after they are detached from EF ObjectContext. So you can return object graph consisted of STEs from web service to Silverlight application, make some changes to STEs and send same object graph back to web service. Applying changes from STEs will handle a lot of work for you. Be aware that STEs are not the best solution for services which should be exposed to general web applications or non .NET clients.
I'm having some issues with dealing with indirectly associated models in cakephp. My current model setup is as follows:
Deliveries hasOne License
License belongsTo Delivery
License hasAndBelongsToMany Product (and vice-versa)
License hasAndBelongsToMany ProductOption (and vice-versa)
I'm trying to save information about ALL of these models inside ONE form. The shortcomings I'm running into are the following:
The form helper only seems able to see the field type one level deep.
saveAll() only seems able to save records one level deep (for multiple model forms).
I'm searching everywhere for the solutions to these issues, but since I'm new to CakePHP, I'm not sure what the newest methods or "correct" methods are for dealing with these issues.
Any advice is much appreciated. Thank you all!
EDIT: I've posted code to my failed attempt here: http://bin.cakephp.org/saved/58501
saveAll() only seems able to save records one level deep (for multiple model forms).
I have stumbled across this limitation in the past and chose, at the time, to work around it by breaking up my form into multiple smaller forms.
One thing to bear in mind when using saveAll and InnoDB tables is that you get atomic transactions, as Cake will perform a rollback if it is unable to commit changes to the database.
So, while you can obviously work around the issue with a few lines of your own code (since Cake's saveAll one-liner doesn't live up to expectations), you would have to spend more time if transactions were a requirement.
Hi I know this is an old post but thought I'd post this to help others, As of CakePHP 2.1 you can save multiple levels of model association using an option on the call the saveAll(), more details here: http://book.cakephp.org/2.0/en/appendices/new-features-in-cakephp-2-1.html#model-saveall-model-saveassociated-model-validateassociated
Example:
$this->MyModel->saveAll($this->request->data, array('deep'=>true));
As for the FormHelper limitation, I'm as lost as you are, I will probably resort to setting the input types manually as my fields don't need too much validation.
I've been reading up on the MVVM pattern, and I would like to try it out on a relatively small WPF project. The application will be single-user. Both input and output data will be stored in a "relational" XML file. A schema (XSD file) with Keys and KeyRefs is used to validate the file.
I have also started to get my feet wet with Linq and LinqToXml, and I have written a couple pretty complex queries that actually work (small victories :)).
Now, I'm trying to put it all together, and I'm finding that I'm a little bit confused as to what should go in the Model versus the ViewModel. Here are the options I've been wrestling with so far:
Should I consider the Model the XML file itself and place all the LinqToXml queries in the ViewModel? In other words, not even write a class called Model?
Should I write a Model that is just a simple wrapper for the XML file and XSD Schema Set and performs validation, saves changes, etc.?
Should I put "basic" queries in the Model and "view-specific" queries in the ViewModel? And if so, where should I draw the line between these two categories?
I realize there is not necessarily a "right" answer to this question...I'm just looking for advice and pros/cons, and if anyone is aware of a code example for a similar scenario, that would be great.
Thanks,
-Dan
For a small application, having separate Data Access, Domain Model and Presentation Model layers may seem like overkill, but modeling your application like that will help you decide what goes where. Even if you don't want to decompose your application into three disitinct projects/libraries, thinking about where each piece of functionality should go can help you decide.
In that light, pure data access (i.e. loading the XML files, querying and updating them) belongs in the data access layer, since these are technology specific.
If you have any operations that don't relate to your particular data access technology, but could rather be deemed universally applicable within your application domain, these should go into the Domain Model (or what some call the Business Logic).
Any logic whose sole purpose is to provide specific functionality for a particular user interface technology (WPF, in your case) should go into the Presentation Model.
In your case, the XML files and all the LINQ to XML queries belong in the Data Access Layer.
To utilize MVVM, you will need to create a ViewModel for each View that you want to have in your application.
From your question, it is unclear to me whether you have anything that could be considered Domain Model, but stuff like validation is a good candidate. Such functionality should go into the Domain Model. No classes in the Domain Model should be directly bound to a View. Rather, it is the ViewModel's responsibility to translate between the Domain Model and the View.
All the WPF-specific stuff should go in the ViewModel, while the other classes in your application should be unaware of WPF.
Scott Hanselmen has a podcast that goes over this very topic in detail with Ian Griffiths, an individual who is extremely knowledgeable about WPF, and who co-wrote an O'Reilly book titled, "Programming WPF."
Windows Presentation Foundation explained by Ian Griffiths
http://hanselminutes.com/default.aspx?showID=184
The short (woefully incomplete) answer is that the view contains visual objects and minimal logic for manipulating them, while the View Model contains the state of those objects.
But listen to the podcast. Ian says it better than I can.