I have a template with some shared fields and a subform defined. The subform contains the shared fields. From another database, I inserted the subform directly from the template. I notice that on the web, the shared fields are not generated. They do not appear in the HTML source at all. Anyone encounter this?
Subject: Shared field problem
You need to copy every referenced elements into each new database. Notes does not let you reference external design elements.
In this case, you’d have to copy both the subform and the shared fields, and not only the subform.
Subject: RE: Shared field problem
Actually, when I insert the subform, I select an external database as the source. Notes doesn´t seem to copy the design element to the current database and it normally the form fine. In fact, one of the forms that uses this subform actually loads all of the shared fields, while another three do not. I am not sure what is the reason for this inconsistant behavior.
As for not using shared fields on a subform, I use this to access a common computed value in any frame. I can´t seem to find a way to do this with Javascript. If someone knows a better way, I would be grateful to know. Thanks.
Subject: RE: Shared field problem
It may be possible that in the databases into which you insert the subform AND where the shared fields did appear, the shared fields have already been defined. If so, it might be wise to check whether the shared field that exists in those databases has the same properties(default value, validation, translation, etc.) as in the template where the subform was defined.
Subject: RE: Shared field problem
The form where the fields actually appear is in the same database as other forms where they do not.
There are no shared fields defined in any of the databases using the external subform and shared fields. This is driving me nuts. It should work!
Subject: RE: Shared field problem
Do the shared fields appear in the list of field names? For example, when editing the column formula in a view, rather than choosing “Simple Function” or “Formula”, when you choose “Field” do you see the shared fields in that list?
Subject: RE: Shared field problem
Yes, they do. I created a new database and copied over a form that uses the subform with the shared fields. The shared fields appeared when I next edited a view. However, when I load this form on the web the fields are not generated.
Subject: RE: Shared field problem
Also I tend to not use shared field in subforms, if there isn’t a very good reason for it. It’s not really wrong, it’s not forbidden, it’s not unsupported, but there can be side-effects.
You just came across the first issue: You cannot copy over the subform without copying over shared fields as well. The same goes for other resources like images, but if you can minimize dependencies, that usually good.
Conceptionally, subforms and shared field are similar, just with different levels of granularity. There are exceptions, but often a field that is used in a subform will not be used outside of it.
Shared fields are slower than regular fields. Admittedly, I’m walking on thin ice here. I should say: They are reported to be slower. I never did any tests myself. Now, many people say, that subforms are slower than putting stuff directly on a page as well. First, I DID testing on that (web only) and never found any measurable difference in performance, even with 50 plus subforms. Maybe this changes with higher loads, maybe not. In each case, if you combine the alleged performance penalty of a shared field with the alleged performance penalty of a subform, it might just not be ideal.
Lastly, shared fields cannot be used in forms (and subforms) that should be available to Public Access users. Forms and subforms can be configured for public access, designer misses the UI widget to do the same for a shared field (you can still add a $PublicAccess item to the design note and it will start to work, but that’s not very robust).
You see, none of my points is too much of an issue. I just don’t like the combination of issues, so I try to stay away from it. Probably down to personal taste, to some extend.
Subject: Shared field problem
I can’t work out this problem, so I am going to replace the shared fields with some Javascript functions added to the top window by the frameset. These are accessible to all frames without a lot of effort. That is, unless someone can tell me why this is a bad idea…
EDIT: How about, because it doesn’t work for image or stylesheet loading? Doh…
FIXED, SORT OF: If I copy the shared fields to each database, the subform loads correctly in all cases. The subform can still be referenced externally. This is better than no re-use at all.
Subject: RE: Shared field problem
“If I copy the shared fields to each database, the subform loads correctly in all cases”
Hm, this is exactly what Nicolas had suggested in his very first reply. 
And it is indeed the only correct way to do it. Just like with images, style sheets, file resources …
You can still store all that stuff in one master template and have those individual design elements inherit their design from it. That’s what I usually do.
Subject: RE: Shared field problem
Indeed, Nicolas did suggest that (thanks). But he always said that the subform must be copied as well.
You say that the copying the design element is the only correct way to do it. What is wrong with having a library database that you can reference all static elements in directly? This would include CSS, images, JS libraries, subforms etc. This is what I am trying to do and for the most part it seems to be working fine. This cuts down on the number of design elements in a database and reduces maintenance overhead. Isn’t this better than inheritance?
Subject: RE: Shared field problem
I kind of oversimplified to make my point. Most of the time, there are different ways to share resources and they all might or might not work so well in different environments.
First off, for Domino a subform or a shared field is by no means a “static” resource. They can contain lots and lots of code that might finally behave very different in different applications. Whatever you find under “shared resources” in Designer can be considered static. JavaScript libraries - although found under shared code - are usually static as well, but some people still prefer to store their CSS or JS on pages, which can contain computed text to even make those non-static.
For truely static resources, it might in many scenarios be the best solution to store them in a central repository, especially, if you make sure that they are cached by the browser (e.g. by adding an expires header).
The next question is, how you build the reference to resources. If you use pass-through HTML to load CSS, images or JS libraries, you have can virtually do whatever you want, but either have to make sure that the path to your repository does not change, or you have to make it configurable.
If you use Designer’s GUI widgets to refer to resources in other databases, it’s a different story. In most locations, you can only select the source database once and cannot change that later on easily. In this case, the connection is established using the repository db’s replica ID, which might or might not be nice. It surely doesn’t suite the concepts of templates very well, so will not want to have a template and production database for your repository.
Inheritance of single design elements helps with most of these issues at the price of redundant storage and the need to make sure the inheritance doesn’t get broken. Inheriting, say, a CSS into many databases also makes it less comfortable to configure far-off expires headers.
So, usually there is no single “best” approach, but you have to decide case-by-case. When subforms and shared fields are concerned, I’d go for design inheritance.
Subject: RE: Shared field problem
Yep, this is what I initially suggested.
You have to keep in mind that Notes is (usually) a decentralized environment.
People are replicating data from cascading servers on huge environment, so data is rarely central and even more rarely real time.
If you are designing a WEB domino application however, it makes more sens to regroup several design elements centrally, because you can mostly refer to them through URL and your users will access it centrally, without replication.
For a notes FAT application however, referencing design elements all over the place actually makes it a lot oess reliable because design msut be replicated across all replicas in a big cascading server environment, just like data, and may be subject to design conflict. In that context, the best code reusability is, IMHO, a copy of all design elements to the target database.
Yes, it means when you update an element in database A, it will not update in database B.
But this has also a lot of advantages in a decentralized environment.