The generated designer.cs properties are private by default (at least without manual tweaking of generated code). This makes coding against something like a UITableViewCell feel much different than if I were doing this in Objective-C.
The popular way in the case of UIxxxViewCells, at least from what I can tell, is for the UIxxxViewDataSource to populate the IBOutlet properties, and that the cell should only be responsible for anything related to drawing/rendering the view.
With Xamarin.iOS, we are unable to access these properties from the data source, and instead are required to provide additional setter methods to populate the cell. In this way, the cell is responsible for setting it's own properties.
Is this just "The .NET way" of doing things?
It's so that we don't break encapsulation by default.
The outlets belong to the object they're on, it should be able to choose whether they're able to be modified from the outside. The fact that they're properties is an implementation detail of the Xamarin.iOS outlets system - you should think of them as private fields.
If you wish to expose them, you can create properties that do so - preferably read-only.
It was probably done that way because that's how the other GUI designers in MonoDevelop worked at the time (still do). Auto-generated bindings to the native controls used by the user-designed control for toolkits like Gtk# are also created as private.
I'm not sure if other UI designers for .NET work (I've never used Visual Studio to develop GUI apps using Windows.Forms or WPF).
Feel free to file a feature request on https://bugzilla.xamarin.com to make them public - I'll gladly implement it, I think it probably makes more sense for them to be public. I haven't changed it mostly because no one has expressed that they wanted it be any other way.
Related
We are working on plugin for ReSharper and we want to make our plugin extensible. Seems, we should use ShellComponent attribute to do it but we can not find any examples. Could anybody enplane how to define custom extension point and how to manage extension. Example of code of extension point and extension implementation would be very helpful.
Thanks.
If you're looking to write a plugin that can extend ReSharper, you need to tell ReSharper about the classes in your plugin, by marking them with the [ShellComponent] or [SoutionComponent] attributes. These attributes have different lifetimes - a shell component lasts the lifetime of ReSharper itself, and a solution component is created when a solution is opened and disposed when the solution is closed.
To make ReSharper do something useful with your components, they typically have to implement an interface, such as ICodeCompletionItemsProvider, and sometimes have to use a different attribute, such as [CodeCleanupModule] (which itself derives from ShellComponentAttribute). There are many extension points in ReSharper, and the one that's appropriate for you depends on what you're trying to do - refactoring, unit test provider, code cleanup, code completion items, etc. The devguide provides a good introduction to the more common extension points.
But if you want to make your own plugin extensible, then your component needs to work with a kind of provider pattern, by deferring work to multiple provider instances. For example, code cleanup works by deferring to multiple code cleanup modules, each responsible for cleaning up a different aspect of your code (whitespace, ordering, etc). To do this, your component should take in a collection of providers in the constructor. ReSharper's component model will automatically create a collection of these types and pass them to. More specifically, you should have a constructor that takes an IEnumerable<T> or IViewable<T>, where T is the interface of the provider you're going to define and call. The IEnumerable<T> will give you a simple collection of providers, but IViewable<T> represents an observable collection, and allows you to subscribe to notifications of new providers being made available from the component model.
For our Xpages application stack we have to create cca. 100 controls that will cover our new UI parts/helpers and some additional services. These controls are meant to be very general and have to be used by many Xpages applications. Now question is how to share these controls among applications(databases). Controls need some managed beans to work, also some CSS, JS and images. To copy the whole stuff into each application and maintain it somehow is not the way (even design inheritance doesnt help here). What's more ... mixing these 100 controls among application specific controls is real hell as controls doesn't support any namespaces or some packages grouping (like java in Package Explorer), so at the end we have very long list of controls in DDE which is nightmare to navigate and work with.
We tried to use Extension Library approach and followed this tutorial
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Master_Table_of_Contents_for_XPages_Extensibility_APIs_Developer_Guide
... but honestly I tried 3 times on my computer from scratch and even example project from tutorial didn't work properly and still caused some errors in update site project. My colleague also tried this on his computer with no luck. And entire process as described in the article above is set of many java classes, XML and configuration files even for small control (eclipse plugin project -> feature project -> updated site project and then you have to install this update site test it and when bug occurs you have to run another cycle ...). Comparing to e.g. this http://tapestry.apache.org/component-classes.html its extremely heavy weight approach in Xpages.
So my question is, is there any other approach that can help us in this area to share controls among applications? Or is there any update expected in this area for upcoming Notes release e.g. R9.1 ?
the most efficient way to share controls is an extension library. It does come with a learning curve. You could use Nathan's XSP Starter Kit to ease your pain. Alternatively you can use the import/export plug-in from OpenNTF to move controls (and their supporting files) around.
In any case: XPages custom controls do support name spaces and grouping -> just have a look at the property panel of a control. You can define:
the namespace (defaults to xc, but you are free to design your own)
the group it should appear in
icons
how it looks at design time (to hide the inner workings)
So step 1 is to group and clean and then think about the distribution. Extlib definitely would be best.
There is good ol' method for sharing design elements in NSF: templates. You can make your database a template, and then inherit just specific design elements by copy/pasting them at designer level. In design element's properties view, Design tab, look for "Inherit from the design template" property. It contains template name from which you copied the element. Watch out for the property "Prohibit design refresh or replace to modify", it should be off.
This has some consequences when deploying the application to production, though, so please, read the documentation/help about template inheritance. Especially combination with XPages/custom controls requires the template to be built and signed.
We use it to share custom controls like application layout and picklists with no problems.
I tried the simpledroid with INotifyPropertyChanged and ICommand successfully.
I want to do the same with monotouch and xib designer,but without TouchDialog. Is there a way to implement without inheriting from mvx class as in monodroid?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
I understand what is your goal.
I think you want to start learning MvvmCross for Monotouch with a basic application example as you probably did with SimpleDroid. I tried to do the same without success.
Why ? Because SimpleDialogTouch is an "Advanced" example in my opinion. When you learn Monotouch, you use xib to design your view. But the sample tells you to learn a new tool "Monotouch Dialog" which is a way to display controls programmatically.
You get those errors because the sample implements the ViewModel only for Dialog and not for xib or classic binding.
Finally, you will have to dig into MvvmCross to build your own SimpleTouch implementation. The problem is that you don't have a lot of documentation, but Stuart is the best supporter for a beginner or you can switch to advanced Mvx features if you don't need to understand the underground of MvvmCross. There are a lot of samples, tutorials and posts to tweak Mvx.
Hope that helps.
Is there a way to implement without inheriting from mvx class as in monodroid?
I don't believe this is supported in the current source.
There is an effort underway to separate out the databinding code in MvvmCross so it can be used more easily with other frameworks - e.g. we might try porting MvvmLight across too. This is where my effort is currently focused.
If you need this now, then I think you could fairly easily create this simple binding yourself if you wanted to - but you'd have to take a look at what the SimpleDialog version does - it's not too big a code to copy across to the XIB version - https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Dialog.Touch/Simple/MvxSimpleTouchDialogViewController.cs
But... why not just implement a proper portable MvxViewModel instead?
Is it possible to do the same with MonoMac without Dialog as Portable Library in MonoMac or XaMac in supported now?
Portable libraries are not supported in any release from Xamarin yet - there is an unofficial installer that Jeff very kindly provided - but it's not a release...
For MvvmCross MonoMac/XaMac support, there is one non-PCL version from #deapsquatter around, but I don't believe this has data-binding yet.
I will be working on a PCL and data-binding release for MonoMac or XaMac - but it's on a spare time basis - no-one's come forward with a customer project to fund that work yet. If you or anyone wants to assist with this port, then you are very welcome... but it will be quite technical work - there are changes I intend to make 'under the covers' - so the easiest place for others to help will probably be in later work - adding more views, more bindings, doing QA, making samples, etc.
Note: "Simple" bindings are not the future for MvvmCross and may get dropped from a future release. However, this will only happen after I've separated out the Binding code so that it can be used with other libraries - the first of which will probably be a simple binding example.
I personally don't see much difference or advantage in using these so-called Simple bindings... but maybe I'm missing something...
I am creating a series of window mockup templates based on the excellent Mockups library available on CodePlex.
I'm using their BaseMockup as the base for my control as well, and I followed the same outline of the steps listed here for sub-deriving from existing controls (Create a new empty class, add your default style to /Themes/generic.xaml, etc.)
The control is working great - the only thing is that it doesn't show up in the Assets library. I think this is because it's sub-derived, or because I need some attribute (the equivalent of the ToolboxItemAttribute for WinForms controls? ... which didn't work) to get it hooked up.
When I modify the code to derive directly from Control, it shows up - no custom attribute necessary. Of course that defeats the purpose of what I'm trying to do though...
The only thing I can find are several articles telling me to muck with registry keys, and none of them are clear or suggest a definitive way to do this with Blend 4. That last one advertises as a Blend 4 tips article, but admits at the end that it plagiarizes the content from the other two (for Blend 3).
Is that my only option - register my DLL? Is there a better way to do this?
A while ago I wrote a blogpost about this. I've included a .reg file and a .bat file for setting up the register and some directories. I think that's what you are looking for.
I believe you do need to muck with registry keys. Specifically,
32 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
64 bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NET Framework\v4.0.30319\AssemblyFoldersEx
Create a new key with the name of your control assembly. Then edit the Default string value under this key and set the value to the directory where the control assemblies are installed. See here for a full example (using the Silverlight paths).
Found it - there is an analogue attribute after all, it's ToolboxBrowsableAttribute.
You have to go through a little more rigmarole to get it set up, but it works great - no registry mucking necessary. It requires creating a designer metadata provider class, attributing your assembly so it's designer-discoverable, and then adding the attributes to your sub-derived controls inside your metadata provider.
Make sure you choose the appropriate version of the page for your version of Visual Studio, because the interface changes a good bit between 2008 and 2010.
This article on CodeProject has some good, real-world examples of setting this up. They're all in the 2008 style though, so bear that in mind if you're using 2010.
Background
I'm going to develop a new web-application with java. It's not very big or very complex and I have enough time until it'll "officially" start.
I have some JSF/Facelets development background (about half a year). And I also have some expirience with JSP+JSTL.
In self-educational purpose (and also in order to find the best solution) I want to prototype the new project with one of action-based frameworks. Actually, I will choose between Spring MVC and Stripes.
Problem
In order to get correct impression about action-based frameworks (in comparison with JSF) I want to be sure that I use them correctly (in a bigger or a lesser extent).
So, here I list some most-frequent tasks (at least for me) and describe how I solve them with JSF. I want to know how they should be solved with action-based framework (or separately with Spring MVC and Stripes if there is any difference for concrete task).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
Thanks in advance for explaning how these items (or some of them) can be done with action-based framework.
I'll do my best to answer regarding Stripes. I've used Struts and JSF in the past, but not recently, so at best I have vague notions and feelings about them.
We are intimately familiar w/ Stripes, use it for most everything now, and really enjoy it. It is easy to jump into, supports many of the complicated scenarios, but you are also free to work OUTSIDE of it, which is really important when you want to build your own ajax widgets or talk to another system or something.
If you go the stripes route, I definitely recommend buying or download the book. It is a one stop shop for everything you need for Stripes, and is practically the only documentation for Stripersist (really nice feature, but NO web docs).
Rendering content: I can apply ready-to-use component from standard jsf libraries (core and html) or from 3rd-party libs (like RichFaces). I can combine simple components and I can easily create my own components which are based on standard components.
This is similar. Core, Html, Fmt, etc. as well as any custom tags you find, inc. display:tag, pack tag, and create your own. However, obviously you do not deal at the component level now, you deal with a tag that determines what is on the page / sent to or from the server.
Rendering data (primitive or reference types) in the correct format: Each component allow to specify a converter for transforming data in both ways (to render and to send to the server). Converter is, as usual, a simple class with 2 small methods.
Stripes has many built in converters, and it is easy to create custom converters for your more complex data types. Stripes supports very complex data structures to be mapped with little hassle. Combined with Stripersist, for example, I can put my model object directly on the ActionBean, put a few of the fields on the form, and Stripersist will hydrate the model from the db (based on its PK) and update that with the fields I put on the form - all before releasing control to me on the ActionBean.
Site navigation: I specify a set of navigation-cases in faces-config.xml. Then I specify action-attribute of a link (or a button) which should match one or more of navigation cases. The best match is choosen by JSF.
Navigation in stripes is based on what you name the ActionBeans, initially. There is no xml. Additionally, pretty urls are an annotation at the ActionBean level in Stripes 1.5, so you can do things like #UrlBinding("/{$event}/{model}") where /view/5 would take you to the "view" event handler for your Model object with the ID/PK of 5.
Implementing flow (multiform wizards for example): I'm using JSF 1.2 so I use Apache Orchestra for the flow (conversation) scope.
While I only am vaguely familiar with the concept of conversation scope, Stripes has Wizard Form functionality, but I haven't used it and am unable to really expand on that. I think it is a similar idea though.
Form processing: I have a pretty standard java-bean (backing bean in JSF terms) with some scope. I 'map' form fields on this bean properties. If everything goes well (no exceptions and validation is passed) then all these properties are set with values from the form fields. Then I can call one method (specified in button's action attribute) to execute some logic and return string which should much one of my navigation cases to go to the next screen.
Not drastically different. Instead of components on your [action] bean, you now have Java or custom types. ActionBeans are created per request and thrown away, unless you do something like put it in session, or wizard, or whatever. This is nice, because all the instance variables get mapped to the data from the form, you use it, then throw it away, and don't have to deal with any synchronization issues like struts did. After you do your thing with the data, Stripes lets you send a ForwardResolution (OK status), Redirect, or Streaming (JSON, file, etc). The Redirect-after-POST pattern is implemented nicely with the idea of flash scope (3/4 down the page).
Forms validation: I can create custom validator (or choose from existing) and add it to almost each component. 3rd-party libraries have sets of custom ajax-validators. Standard validators work only after page is submitted. Actually, I don't like how validation in JSF works. Too much magic there. Many standard components (or maybe all of them) have predefined validation and it's impossible to disable it (Maybe not always, but I met many problems with it).
Stripes allows validation in annotations on the instance variables on the ActionBean. They allow some defaults, required, maxlength, etc. or you can always create your own. The default is easy to add and flexible, while there is always the ability to make something completely customized.
Ajax support: many 3rd-party libraries (MyFaces, IceFaces, OpenFaces, AnotherPrefixFaces...) have strong ajax support and it works pretty well. Until you meet a problem. Too much magic there as well. It's very difficult to make it work if it doesn't work but you've done right as it's described in the manual.
This was my big problem with the JSF way of doing things. Even if you did get the widget right, you're still stuck with THAT widget. With Stripes, you can use whatever latest and greatest Jquery has to offer, and as long as you send the right GET or POST to the server, stripes knows what to do with it and can easily send JSON back. I think component frameworks fit a niche a few years ago much better when AJAX was hard, but JQ makes it so easy now.
User-friendly URLs: people say that there are some libraries for that exist. And it can be done with filters as well. But I've never tried. It seems too complex for the first look.
#UrlBinding, it's as easy as that.
My answer is not the one you want to hear: Don't switch from Component Framework to action framework
I switched the other way around after many years of action framework development and I'm never going back.
Of the 8 use cases you mentioned, only one comes to mind where Action frameworks are obviously better, and that is URL design / friendly URLs. It can be done in component frameworks as well, but much easier in Action Frameworks (especially in Stripes where you just annotate your ActionBean with the url).
I would advise you to try wicket, it is very easy to learn (much easier than JSF) and it let's you re-use many existing components as well.