Why does Livecycle Designer need to lock scripting on objects with children that are fragments??

[Former Community Member]

Can someone tell me why Livecycle need to lock scripting on objects with children that are fragments??

I mean, just because I have a fragment (which you can't edit the script for), why does Livecycle need me to NOT edit say the initialise event on the Main form.

Yes, I can remove my fragments, edit and reinsert.  Also if the event already has a script, I can edit the xml.  But neither of these are terribly convenient.

Couldn't there be a better way?

[Former Community Member]

The purpose of the fragment is to create re-usable or standard components. In most cases the fragment is not created by the same person designing the form and they do not want the from designer to modify any part of the fragment (it is a separate XDP file). There may be code in that fragment that relies on the structure that exists. If you have the rights you can always edit the fragment and when your PDF is created the changes will be picked up.

If you want to be able to modify the fragment while it is in Design mode sounds to me like you want to add a component to the object library. This will allow you to have a reusable piece of a form that you can modify on a form by form basis. To do this simply build the piece that you want. Lasso the entire form and drag it onto the Custom library. When you release it a dialog will pop up allowing you to name your component. Now on any form design you can drag your new component onto the canvas and all methods/properties and code will come with that component (allowing you to modify it for that form as you see fit).

Note that you can create your own libraries to hold your components if you see fit. Also if you put your libraries on a shared drive, you can share components between Designers.

Paul

[Former Community Member]

Thanks Paul,

I guess the question was more at a macro level. 

I want to use fragments, because it's good practice - but lets say I place a fragment into a subform, along with a lot of other objects.  Now, I can't set code on the subform's initialise event, because it contains a fragment (as well as a lot of other things).

Now I didn't want to change the fragment - just apply a script to an event of it's container.  Is that a reasonable thing to do, or is it best practise not to do that?

[Former Community Member]

Once the fragment is designed the idea is not to change it. You can still access all of the objects (programatically) within the fragment but if you want to change something in that fragment you do it back in the source of the fragment.

Paul

[Former Community Member]

Hi Paul,

Thanks - but what if I don't want to change the fragment, but the subform it is contained in..

e.g. imagine the hierarchy

form

subform1

subform1_1

textField1

fragment1

subform1_2

subform1_3

     ....

What if I want to write some code in the "initialise" event of subform1?  or  "preprint"?

I can't - unless I write it before I add the fragment.  Otherwise, the script editor is greyed out, because subform1 contains a fragment.

Regards,Tim

[Former Community Member]

Only the subform that conatins the fragment is greyed out anything else in that structure is available to you. If you have to add code to the fragment you will have to Edit Fragment and add it there. The idea is to have everything self contained within that fragment for reuse. It is like an include statement in programming (if you understand programming)

Paul

[Elaine_Schmitz]

Interestingly enough, the fragment code can reference script code outside

itself (in the parent form that houses it), and the parent form can

reference script inside of the fragment. We thought this was pretty cool,

and useful in the case where we have a "search" fragment that sits on many

forms... when the search fragment code completes, it has to hide itself,

show its parent form with search fields populated. Since each parent form

contents were wrapped in a subform called "mainContent", the search

fragment could reference this node and turn on its presence.

--Elaine

[Jono_Moore]

What if you were to wrap the fragment in a subform?

[Former Community Member]

Thanks Guys for your time in answering this ...

I've done some more investigating, and you are correct - only the subform containing the fragment has scripting prevented.

However, I then tried adding a Script Fragment to the form (as well as a fragment containing objects) - this was added to the variables of the main subform, and had the effect of locking out scripting on events of the main subform.

Then I tried wrapping the regular fragment in several other fragments - none of which I could write a script for.

Is this normal behaviour?  Should I use Script Fragments in a different way?

I've attached the form + fragment + script fragment here ...

[Former Community Member]

Thanks Elaine,

Yes we also make calls in and out of the fragments - it makes it useful to provide a "common interface" between the reusable items

One thing I would really like to see though is the ability to define custom interfaces and over-ride properties.  I mean it would be really good to define a property in a fragment, which can be set at design time.  i.e. a Custom Label text value or such.  Similarly, it would be good to be able to define a fragment instance as mandatory (or non-mandatory), and have the fragment define which fields within it are mandatory, or how the validation behaves.

I guess I'm looking at fragments with my "object oriented" hat on - it would be nice to create fragments as re-usable classes, which can then "wrap" base classes, or have interfaces defined..