SubSonic provides the overrideable methods BeforeUpdate and BeforeInsert for doing validation. Is there a way to hook into the BeforeDelete event, if such a thing even exists?
I am not aware of any BeforeDelete event but you could always override the Delete method and handle it there. Just remember to put any overridden methods in a seperate file(SubSonic classes are partial) the convention is to put that file in an "Altered" folder and handle that there.
From what I remember, objects don't have a Delete method. You need to delete via a controller (at least in my templates!).
In my templates, I have methods PreDelete/PostDelete, PreDestroy/PostDestroy. We may have added these ourselves.
Take a look at this article with some sample code:
http://blog.lavablast.com/post/2008/08/SubSonic-v21-Controller-and-Utilities.aspx
(we have other articles on the same controllers on our blog - but they were for v2.0).
Related
I have a general JSF problem, I found no nice solution for yet. See the picture for a general idea. I have a workaround solution (sorry for the typo in the image) in place that solves the problem by a listbox. However the desired solution is to display all existing versions next to each other (probably always around 1-3).
I have a view with a tree and picklist. There is a complex flow regarding the interaction between list and tree, e.g. you can only move models to subgroups, not top-level-groups and much more. I created a handler class that manages this behavior and translates it to service calls.
Now, a new requirement came up. There are several versions of this tree that should be displayed all together on one page. My gut feeling is that managing n versions in one handler is a big mess as I need to store several things in the handler already for one version.
In React, I would create a component that wraps the tree and all of the interaction. However, in JSF I'm not so sure what is the best practice here?
I would be happy about suggestions and ideas, I'm not expecting Code :)
I found a solution that fits my needs and I post it here hoping that it might help other people as well :)
So on my view I have several tree views with complex interactions. For example, if an item within the tree is moved, the operation is immediately reflected in the database. As I use JPA, I need to translate this to an entitymanager call.
The views are either displayed in a list or just one-at-a-time via a dropdown select.
Anyway, the idea is that every complex view component has its own controller with a reference to an entitymanager and a transaction, while having just one JSF handler class. If JSF would allow to create multiple handlers (like #{handler_1}, {handler_2}), the problem could be solved in a different way. But as JSF works name based and the name {#handler} always refers to the same container managed thing, this is no option.
The handler class is ViewScoped (or SessionScoped, if you prefer). For each tree component it has a ComponentController class that receives the EntityManager and the UserTransaction as well as the related data form the handler via constructor injection. This way, the handler can delegate all commands to the Controller while being DRY.
With this solution, the controller logic can be re-used regardless how many tree components exist. Each view elements binds a specific controller via handler.controllers.get(id).
All other solutions did not work for me as they are not able to perform database operations on view interactions.
I am fairly new to ember. I have an existing Ember App and i need to implement a functionality in it. I have a Ember Object as below
`import Ember from 'ember'`
CallService = Ember.Object.extend
... other code here
_updateConnectedLeadId: (->
console.log "Do i get here??"
**pass the route action here**
).observes('some_other_here')
`export default CallService`
Unfortunately, i couldn't put the whole code here.
My route looks like
ApplicationRoute = Ember.Route.extend
actions:
showLead: ->
console.log data
console.log "did i get here?"
#transitionTo('dashboard')
`export default ApplicationRoute`
I tried using #send('showLead'), #sendAction('showLead') in my method but no luck.
My main intention is to make a transition once the console.log "Do i get here??" is displayed. I am not sure if i am on the right way here.
I also tried using #transitionTo('dashboard') and #transitionToRote('dashboard') directly but it throws me errors.
I have been stuck for a day on this now and i am clueless.
I'll be grateful for any guidance and help. Thanks
You have the problem that you are trying to trigger a route action or trigger a transition from within an Ember.Object, named call service. The code you create is unclear about where your custom object is being created; where the observer is triggered due to a change to object's property update, and so on.
Nevertheless, I tried to provide a working example for you. If you open the twiddle, you will see that I created a my-object instance within index.js route and pass it as model to my-component. When you click the button within my-component.hbs. The my-object instances dummyVariable is toggled and the observer within my-object executes. The tricky part here is that I passed index route itself as ownerRoute property to my-object instance; so that I can trigger the index route's dummyAction from within my-object.js with
ownerRoute.send('dummyAction');
so that related action executes and transition to my-route is performed. Although, I believe this might solve your question; I am not quite happy about the design. I do not think, it is a good way for Ember.Objects to know about routes, actions, controllers, etc. I believe the proper way is observing object's relevant properties from within this constructs and perform necessary actions by their own. Moreover, you might consider creating a service instead of an object and inject the service directly to your route instead of creating an instance of your class extending Ember.Object. If you have to extend from Ember.Object you can just inject relevant route, controller, etc to the instances of that particular object class by using an instance-initializer if you need.
Anyway, please take a look at the twiddle and ask more if you need to. I will be happy to help if I can.
I have a 'document' table (very original) that I need to dynamically subset at runtime so that my API consumers can't see data that isn't legal to view given some temporal constraints between the application/database. JOOQ created me a nice auto-gen Document class that represents this table.
Ideally, I'd like to create an anonymous subclass of Document that actually translates to
SELECT document.* FROM document, other_table
WHERE document.id = other_table.doc_id AND other_table.foo = 'bar'
Note that bar is dynamic at runtime hence the desire to extend it anonymously. I can extend the Document class anonymously and everything looks great to my API consumers, but I can't figure out how to actually restrict the data. accept() is final and toSQL doesn't seem to have any effect.
If this isn't possible and I need to extend CustomTable, what method do I override to provide my custom SQL? The JOOQ docs say to override accept(), but that method is marked final in TableImpl, which CustomTable extends from. This is on JOOQ 3.5.3.
Thanks,
Kyle
UPDATE
I built 3.5.4 from source after removing the "final" modifier on TableImpl.accept() and was able to do exactly what I wanted. Given that the docs imply I should be able to override accept perhaps it's just a simple matter of an erroneous final declaration.
Maybe you can implement one of the interfaces
TableLike (and delegate all methods to a JOOQ implementation instance) such as TableImpl (dynamic field using a HashMap to store the Fields?)
Implement the Field interface (and make it dynamic)
Anyway you will need to remind that there are different phases while JOOQ builds the query, binds values, executes it etc. You should probably avoid changing the "foo" Field when starting to build a query.
It's been a while since I worked with JOOQ. My team ended up building a customized JOOQ. Another (dirty) trick to hook into the JOOQ library was to use the same packages, as the protected identifier makes everything visible within the same package as well as to sub classes...
How can I implement a Multi-DataTriggerBehavior?
I already have one DataTriggerBehavior in place. But I need a trigger that is based on an event and multiple conditions.
I'd recommend you to create your own Behavior to handle this.
These are the steps for a possible solution.
Because you will need to somehow invoke a VisualState in your Behavior's code behind, you have to change the VisualStateManager defined in your xaml to ExtendedVisualStateManager (see the implementation in this post) as the built-in VisualStateManager's GoToState method doesn't accept Grid as its parameter.
Create a Behavior and attach it to a proper Control. I assume you want to do something when an event of the Control is raised. So you need to create a handler for this in your Behavior code-behind.
Create dependency properties that map the properties defined in your viewmodel and subscribe to all their property changed callbacks. You might need local flags to tell whether all of them are updated or not. If they are, in your event handler, call ExtendedVisualStateManager.GoToElementState. Note that you might also need to create a dependency property to reference your Grid and a few others to map your VisualState names.
Attach the Behavior to your Control in xaml and data-bind all its dependency properties.
Hope this makes sense.
In MonoRail controllers can be adorned with the Helper attribute to make helpers available in views. Is there another way to register helpers, perhaps via configuration file or dependency injection, with controllers? I'm keen on avoiding creating a base controller just for the purposes of providing helpers and adding yet another controller to the controller hierarchy.
IControllerContext has a Helpers dictionary. All controllers expose IControllerContext via the ControllerContext property.
Another option is to implement an IHelperDescriptorProvider to replace the default one (which reads helper descriptors from [Helper] attributes). Your implementation could read helper configurations from a config or whatever you want.