I'm trying out ASP.NET MVC Framework and would like to create an ajax helper method. Basically this helper would act like ActionLink but without encoding its link text. It is rather trivial to write as an HtmlHelper, you simply have to write your own version of GenerateLinkInternal. This isn't working for AjaxHelpers though, as the ajax version of GenerateLink is indirectly calling ToJavascriptString (through GenerateAjaxScript) which is internal, thus cannot be called outside the MVC assembly. I sure can rewrite the whole thing, but it seems way overkill, is there a better way?
Ultimately, I'd like to make this helper act like BeginForm to make the link surround a block of HTML. I've not looked at it yet, but I assume that it uses ToJavascriptString too. I've searched the web and, looking through the MVC source code, I begin to wonder if I'm completely on the wrong track.
Thanks
Update: The more I look at this problem, the more I think that there's simply no solution. Whoever wrote the MVC Framework didn't think about helping people write their own helpers!
Update: I've ended up writing an helper that pretty much duplicate AjaxOptions functionality.
You could probably do this a lot easier by writing your own helper from scratch (i.e. don't make calls to any of the Html.ActionLink()/Ajax.ActionLink() methods) simply by using Url.Action() instead.
For example, it's pretty trivial to do this:
public static string NonEncodedUrl(this HtmlHelper helper,
string linkAction, string text)
{
// Get a new UrlHelper instance in the current context
var url = new UrlHelper(helper.ViewContext.RequestContext);
return String.Format("{1}", url.Action(linkAction), text);
}
You can of course extend this with overloads and extra parameters to suit your own needs.
Related
Tailwind offers a feature where you can give an input element the peer class and then, in a sibling element use the peer-invalid: pseudoclass to apply conditional stylings. This is commonly used to provide helper text when a form field is not valid.
I don't see how this can be tested in JS-DOM though, as JS-DOM doesn't have access to the actual CSS when it is just rendering components in unit tests.
The information I have seen about getting JS-DOM to use CSS at all is kinda sketchy, so I was wondering if it's even worth trying to get it to evaluate a bunch of tailwind classes in a NextJS/Jest/RTL project. I'm using Tailwind 3 so it's not even like I have a big file full of generated classes I could try and pass to JS-DOM :/
So can it be done? (Note the hard fact please mods!!!)
(And, somewhat more subjectively, should it be done? Or is there a better way to approach this?)
Creating in-repo-addon in Ember.JS gives a lot of possibilities. Today I've stumbled into a case when I wanted to register all classes in directory (for example my-dir) into Dependency Injector (same way it's done with services by Ember, but I wanted to use some other namespace).
For example I want to allow developer to create multiple classes inside proxy directory, and register all of them in DI under proxy: namespace. So later we can use:
Ember.Component.extend({
myProxy: Ember.inject('proxy:my'),
});
You'll need to do this using an initializer. More details on this here: https://guides.emberjs.com/v2.12.0/applications/dependency-injection/
The hard part may be getting all proxy items in s folder to automatically register ...
Edit
Looks like I didn't spend enough time thinking about this. You should be able to do at least part of this easily. There are two parts to this.
Part 1
Ember currently uses the ember-resolver to handle lookups for various items. If you check the tests for the resolver you'll notice that you should be able to map in anything you want: https://github.com/ember-cli/ember-resolver/blob/master/tests/unit/resolvers/classic/basic-test.js
So in your case, if you do a Ember.getOwner(this).lookup('proxy:main') from within an Ember instantiated class (a route, controller or component for instance) it would look in app/proxy/main.js which your addon could be populating.
Details on the Ember.getOwner lookup are available here: https://emberjs.com/api/classes/Ember.html#method_getOwner
Part 2
So at this point you can lookup proxies (which would be doable in an init method). But if we want to get truly elegant we'd want to allow Ember.inject.proxy('main') syntax.
Doing so would involve calling a private method inside of Ember.inject in an initializer. Because that naming scheme is changing in the new Javascript modules RFC, it may be unwise to try to add this syntactic sugar ...
So I'd advise avoiding touching that private API unless it's really important to your app design.
In the notes of this commit, the Ember team have made it very clear that App.__container__.lookup() is not the way to get at controllers. Instead we should use the needs property.
I understand the rationale behind this, and the idiomatic way to access singleton controllers.
However, in my app, I have some cases where I need instance controllers. In that case, I am using App.__container__.lookupFactory() to get at the prototype which I can then create() or extend()
Is there a better way to do this (without using __container__?
Edit:
Here is an example use case.
App.MyContainerView = Ember.ContainerView.extend
...
addChildView: ->
#get("content").pushObject(App.MyChildView.create(...))
The above example will push a new view onto the stack (allowing views to be dynamically created)
However, these views will (may?) not have the right container (and other properties?) set due to being created using App.MyChildView.create(). This is especially true in cases where we are doing a partial integration of Ember into an existing app.
The way to create these views would instead be:
App.__container__.lookupFactory("view:my_child").create()
In which case everything would be ok.
Additional use cases exist, for creating instance controllers outside the context of the router.. but the idea is the same.
I don't know if you're still looking for an answer. I am also struggling with how to do things "the Ember way".
This answer put me on the right track, and should be relevant to your question:
"Please ensure this controller was instantiated with a container"
As for me, I had the same problem as in the above question: when I manually instantiated my App.AnyOtherController with App.AnyOtherController.create(...), then inside this controller, I could not access dependency injections (such as a session object that I make available to all my controllers and routes).
Instantiating the same controller this way solves the problem by giving the controller a container:
this.container.lookupFactory('controller:any_other').create(...)
You should be able to access this.container from any view, and I guess, any controller, as long as they have been given a container.
You can Ember.String.decamelize('AnyOther') to convert the CamelCase controller name to a suitable string.
More on containers here: http://ember.zone/beginning-to-understand-the-ember-js-container/
If it doesn't help you, I still hope this helps someone out there, as this container stuff is a bit tricky at first...
I have an app built on Model-Glue: Unity that contains some search forms. I need to trim leading and trailing spaces from search strings before using them to query the database. I'm also keeping the search terms in a bean that a user can save and re-use.
My problem is that I am unsure where to perform that trim(). The bean seems to be the wrong place for it, as I'm keeping the bean simple (no logic). Normally I would take care of that when updating the bean, but I'm using MakeEventBean to keep things simple. Re-touching all of the data in the Service layer seems an unnecessary layer of overhead. And, lastly, doing it in the datalayer with the actual SQL query doesn't seem right either. It'll work, but the information in my search bean will still be wrong.
What have you done in such cases?
Disclaimer: I'm not a MG user, so I'm not sure if this will be good and possible approach. Just want to share the idea.
In case of Transfer ORM beans I do such specific things in decorators which extend auto-generated beans.
For example, I can easily override setter setSearchPhrase(phrase), where trim the argument value and invoke original method.
I ended up making my Beans a little smarter than they were. Rather than monkey with every single setThing() method, I added a trimAll() method simple applied a trim() to each of the private properties in the Bean.
I'm new to the Repository Pattern and after doing a lot of reading on the web I have a rough understanding of what is going on, but there seems to be a conflict of ideas.
One is what the IRepository should return.
I would like to deal in ONLY Pocos so I would have an IRepository implementation for every aggregate root, like so:
public class OrangeRepository: IOrangeRepository
{
public Orange GetOrange(IOrangeCriteria criteria);
}
where IOrangeCriteria takes a number of arguments specific to finding an Orange.
The other thing I have is a number of data back-ends - this is why I got into this pattern in the first place. I imagine I will have an implementation for each, e.g
OrangeRepositoryOracle, OrangeRepositorySQL, OrangeRepositoryMock etc
I would like to keep it open so that I could use EF or NHibernate - again if my IOrangeRepository deals in POCOs then I would encapsulate this within the Repository itself, by implementing a OrangeRepositoryNHibernate etc.
Am I on the right lines?
Thanks
EDIT: Thanks for the feedback, I don't have anyone else to bounce these ideas off at the moment so it is appreciated!
Yes, your version is the safest / most compatible one. You can still use it with about any resources, not only data access ones, but with web services, files, whatever.
Note that with the IQueryable version you still get to work based on your POCOs classes, but you are tied to the IQueryable. Also consider that you could be having code that uses the IQueryable and then turns out it you hit a case where one of the repository's ORM doesn't handle it well.
I use the same pattern as you do. I like it a lot. You can get your data from any resources.
But the advantage of using IQuerable is that you do not have to code your own criteria API like the OrangeCriteria.
When NHibernate gets full Linq support then I may switch to the IQueryable.
Then you get
public class OrangeRepository: IOrangeRepository {
public IQueryable<Orange> GetOranges();
}