Why can't you tag entities of type Pattern.any in utterances? I have cases where I want the model to try to learn the entity, but also have cases where there is a clear pattern to when this entity will occur. Is there any way to solve this use case, or the best practice to approach this?
Pattern.any is only for the Patterns, and not for example utterances in the Intents. Patterns do not learn in the sense that you mean. They are rules for matching.
Related
I'm reading about the Laravel Best practices to reduce the code duplication as much as I can, then I read about the repository pattern and I'm following this technique but when I was exploring the https://github.com/akaunting/akaunting open source software for accounting, I saw there is nothing related to respository pattern. I really got confused, so when should I use the repository pattern? if it is helpful when why the good projects not use that pattern? or if there is something better than repository pattern?
This is true for every design pattern: never start with wanting to implement a specific design pattern.
Start by never using the repository pattern (or any other pattern) and when you feel like your controllers are getting really big or your code is getting really hard to maintain take a look at what design pattern might solve your issue.
The given package does not contain that pattern because the people who made it did not need an extra layer of abstraction or chose other abstraction solutions.
Always start simple.
While designing & developing a data-centered project using Entity Framework, I have spent too much time to find a way to accomplish one of the following but have come across nothing practical.
To find an alternative to implement "Polymorphic Association" which cannot be implemented along with "TPC Inheritance Mapping" in EF - since this kind of inheritance mapping fits well with the logical design of my model, or
To find a way to improve the poor performance of "TPT Inheritance mapping" which seems to me is the only practical alternative to TPC.
"TPH Inheritance Mapping", in my opinion, does not make sense from the "database design" and "data validation" point of view.
Besides, since other parts of the project rely almost totally on Microsoft products, I do not tend to switch to other ORM frameworks such as NHibernate.
Now I would like to ask those of you who are professional software developers and have possibly faced this problem, to please advise me about any other available options/solutions. How is this issue usually solved in professional design/development tasks?
Appreciate any guidance in advance
Just playing around I seem to be able to achieve all manner of polymorphic associations. One thing I found helped is to make sure all your foreign keys and relationships are explicitly defined, this will avoid any ambiguity that Code First may encounter. Julie Lerman in her book Code First does mention that foreign keys should be defined otherwise unexpected things with the association mappings may occur.
Hope that helps, if not let us have some code and say what you can't get to work.
Cheers
I have two models, lists and lists_items
I have a basic crud structure for them.
I've also set the hasMany(in lists) and belongsTo(in lists_items).
What I want now is to add an option to edit the list_items themselves in the edit view of the parent list.
Please advice me how to create the proper MVC for that.
(I just can't find out what are the correct element/components/etc that I should use 'to do it right', I can simply glue together some MVC pieces and it will work, but I had enough of classic asp)
;-)
I don't think I am answering your questions because there are other problems I see in your setup (at least I assume there is).
Your naming convention: "lists_items" is usually used for a HABTM relationship, and if it's a HABTM you need to put the words in alphabetical order like: "items_lists". If this is a standard belongsTo, you should name the table: "list_items". This is just per convention.
And you should probably use bake to get familiar with the CakePHP file structure and you can study the relationship code in the models.
Being able to edit related "parent" model data is usually not difficult if you are following convention and reading the manual about relationships.
Keep in mind "doing it right" in CakePHP is following the convention that was laid out in the manual. I know NOT every single thing and detail is covered in the manual as a lot of it has to do with general Object Oriented concepts and general programming concepts (understanding arrays etc).. Learning CakePHP effectively is not an overnight process and the only suggestion I can make is practice, practice, practice and read, read, read the manual over and over again :) Best luck.
As a designer, I like providing interfaces that cater to a power/simplicity balance. For example, I think the LINQ designers followed that principle because they offered both dot-notation and query-notation. The first is more powerful, but the second is easier to read and follow. If you disagree with my assessment of LINQ, please try to see my point anyway; LINQ was just an example, my post is not about LINQ.
I call this principle "dial-able power". But I'd like to know what other people call it. Certainly some will say "KISS" is the common term. But I see KISS as a superset, or a "consumerism" practice. Using LINQ as my example again, in my view, a team of programmers who always try to use query notation over dot-notation are practicing KISS. Thus the LINQ designers practiced "dial-able power", whereas the LINQ consumers practice KISS. The two make beautiful music together.
edit I'll give another example. Imagine a logging tool that has two signatures allowing two uses:
void Write(string message);
void Write(Func<string> messageCallback);
The purpose of the two signatures is to fulfill these needs:
//Every-day "simple" usage, nothing special.
myLogger.Write("Something Happened" + error.ToString() );
//This is performance critical, do not call ToString() if logging is
//disabled.
myLogger.Write( () => { "Something Happened" + error.ToString() });
Having these overloads represents "dial-able power," because the consumer has the choice of a simple interface or a powerful interface. A KISS-loving consumer will use the simpler signature most of the time, and will allow the "busy" looking signature when the power is needed. This also helps self-documentation, because usage of the powerful signature tells the reader that the code is performance critical. If the logger had only the powerful signature, then there would be no "dial-able power."
So this comes full-circle. I'm happy to keep my own "dial-able power" coinage if none yet exists, but I can't help think I'm missing an obvious designation for this practice.
p.s. Another example that is related, but is not the same as "dial-able power", is Scott Meyer's principle "make interfaces easy to use correctly, and hard to use incorrectly."
If your "dial" has only two positions/levels, it sounds like you're simply referring to a façade.
"Progressive disclosure."
You may already be acquainted with the term because of its use with user interfaces -- e.g., "More" buttons. However, the concept is more general.
From "Universal Principles of Design," by Lidwell, Holden and Butler:
Progressive disclosure involves separating information into
multiple layers and only presenting layers that are necessary or relevant.
I call this principle "dial-able
power". But I'd like to know what
other people call it.
I've personally never heard of "dial-able power", and I don't think its an industry standard term.
In the case of LINQ, we'd refer to its design as a fluent interface.
Fluent interfaces are design so that all methods on an object return the same type as that object, and therefore makes method chaining easy. You see the same fluent design in the StringBuilder.Append overloads, fluent NHibernate, and RhinoMocks.
In the case of JQuery, it also uses fluent interfaces for method chaining, but I believe "query" or "DSL" is the proper name for its selector notation.
(Obj-C selectors use the same terminology, but describe something completely different.)
Since its described as a querying DSL, most people can infer that it takes a sequence as input and returns a sequence as output. The query notation is performs roughly the same function as XPath with more bells and whistles.
Hibernate HQL is a querying DSL on top of many SQL dialects, and in a very superficial way regexes are a querying DSL which transform string sequences into a new set of string sequences (you can, in principle, make a fluent interface for regexes, but it would probably make you claw your eyes out).
I need to develop a user interface for inputting something like "if x or (y and z) then do a, b, and c". The data to be entered itself is already quite complicated, how do you wrap it up in an intuitive UI?
Here's my answer from a similar question: Intuitive interface for Composing Boolean Logic?
I would break your interface into two parts: the condition and the result.
Here's an example of the conditional interface:
A Few Thoughts
The interface starts out simple
If it gets complicated, it's because the user built it step by step
No editing or drag/drop - just creating and deleting branches
Conditions are a simple dropdown in this example, but could be more complicated or possibly negated. Basically this interface lets you compose expressions.
I think it's a good idea to avoid this type of interface if possible
Here is an example of how I solved the problem for a bug database. This was done a decade ago on a linux box, so the L&F is rather motif-ish, but it shows the general concept:
(source: clearlight.com)
It works pretty much as you expect. You can change "ANY of the following" to be "ALL of the following" and the labels on the subsequent lines will change from "or" to "and". The "IS" button can be changed to "IS NOT" as well as "Matches pattern" and a few other choices.
You click on the +/- buttons to add additional criteria. You can create logical groups which allow you to do expressions like "a or (b and c)", yet it still almost reads like a collection of English sentences.
In your case, instead of an "Order by" section you might have a "do these things" section.
This would be cumbersome to use if you have to create very complex queries, but if you're needing a complex query you're probably smart enough not to need a GUI like this. This was designed more for the casual user for simple ad hoc queries.
I would definitely change the way this looks if I had it to do over again, but the basic mechanics work pretty well.
Will it always be binary logic like this (just Or's, And's, and Not's)? If so you could have the UI be a logic diagram designer, similar to the ones used in designing circuit logic.
This is a good article
http://www.lukew.com/ff/entry.asp?1007
I used the ideas in that article when building a form for entering Benefit Deduction rates. The short of it is, that he recommends building the form kinda like Mad Libs (remember those books as a kid).