Can you (partly) hide the design of your XPages application when distributing them and how should you do so?
Patrick we hide the entire design for our IQJam and IdeaJam evaluations and all works fine. Not sure about how to hide only "portions" of the app.
Not possible to partly hide specific objects, use these steps to hide the application design completly
Create a two new templates (ntf's) from your nsf application
do replace design using one of the templates to the other with the checkbox "hide forumlas and "lotusscript" ticked
Did not test it for myself, but I would try to pack .class and .xml definitions of code generated for XPages (generally, content of WebContent\WEB-INF folder) into single JAR and deploy it to another database. This would work very well in case your code relies on views and forms in different database so you need not to bother with hiding regular Notes design elements.
There is still the option to decompile such classes what will reveal all bindings/scripts and component names, but at least you make it hard for someone.
Related
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 have a webapp written in JSF, CDI and Seam 3 and I have a properties file with all strings that are rendered in all the views, however, I wonder if it's better to have a properties file for each one of the views or have only one with a lots of values.
Are there any best practises for having a well structured properties file?? Having one properties per view is a good "properties design"??
I thing that having one properties per view means that when you delete one view or refactor something you have to change a lot of files (properties), if you're application is ready for displaying many languages... probably it's better having only one with all the strings...
Any suggestions??
thanks
If goal is multilanguage support. I think you must have one file for each language.
I am new to Sharepoint and I want to make sure I am on the right path.
I am in a highly restricted environment and would rather do this in Visual Studio but am currently in the position where I have to try to get this to work using just the web interface and Sharepoint Designer.
I have created multiple lists that I plan on using in a relational way. I have designed this to mimic a relational database.
I have been able to link these lists for multiple item views and single item views, but need to be able to create items and modify items and so I need to be able to also link these lists and use them in a form.
Is this even possible?
If not, how do I handle updating these items?
Lastly.....
Am I going about this all the wrong way?
Thanks!
Tim
It is possible to do so using visual studio, not sure about SharePoint designer. I've been doing something fairly similar for a client myself however I am able to use visual studio to develop my features and even then it's been a pain.
Part of the issue is that various controls in SharePoint make the assumption about query variables and their meaning to the control (the ListFieldIterator comes to mind on this one). Trying to edit two different list's items on a single page is possible but I don't think it could (or should) be done through the desinger.
Can you get away with two separate forms/pages? If so that makes life much easier where you could do some kind of linking/forwarding between the pages. If you have to have a single page that represents both lists and their many items things get much more difficult. For the later you will almost certainly have to use Visual Studio since you will have to handle quite a bit of the server side logic.
Depends on how restricted you are. If you have access to the server via RDC, you could create these lists bases on a custom schema. All of this can be done using notepad.
A possible solution (that i've heard of but never tried):
a) Create your feature folder, and 2 schema files
b) Get a copy of a basic list schema, engineer it to match your requirements.
c) At the bottom of the schema, you can specify which aspx page is called when i) editing ii) viewing the list. Look at the default out of the box page that is usually referred to, make a copy (customblabla.aspx) and point your list schema to that file (obviously store it along with the out of the box aspx file.
Since you have control over this aspx file, you may able to tweak it do exactly what you want.
Sorry if this doesn't work...
Is there a way to extend the SPGridView control in a webpart such that a user can select the columns that they want to display? Kinda like when creating/modifying a view for a list?
Thanks
SPGridView is not sealed so certainly it can be extended with this functionality. You would need to build your own data store of what users have chosen (a SharePoint list should suffice), make the UI modifications, etc.
One thing I've found when trying to extend the provided SharePoint controls is that even though most aren't sealed, often they aren't designed to be extended either. In some cases the members are obfuscated as well which in some cases can put an end to extension plans.
Make sure you research this as much as possible with some quick proof of concepts before devoting to this development. You may find it's necessary to write your own control from scratch (or find another standard ASP.NET control that provides this functionality and hook it up to a SharePoint data source).
When developing web parts in SharePoint can I inherit from the existing web parts and override their methods?
Or do I always need to start from scratch.
Many Thanks
If they are not sealed, you can inherit from them. In practise, It might work or not depending on how the web part you want to extend.
Most (all?) OTB parts are sealed.
A new toolbar with icon/no buttons sounds more like a design solution. Place the topnav placeholder in a invisible panel at the bottom (so page doesn't crash) and modify the rest visually (css+firebug) . Assuming I am not misunderstanding what you mean.
Its pretty easy to get started with webparts, http://blah.winsmarts.com//2006/05/14/writing-custom-webparts-for-sharepoint-2007.aspx should show you how. From there you should be able to write an RSS reader easily.