From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, T_FILL_THIS_FORM_SHORT autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Preventing private procedure visibility being made public through extension Date: Mon, 22 May 2017 23:24:08 +0200 Organization: Also freenews.netfront.net; news.tornevall.net; news.eternal-september.org Message-ID: References: <05ed8053-be36-4332-8b75-7bca9afd65cc@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 22 May 2017 21:20:44 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="9b3d2a1e3e89aad2dad622ef24c63c38"; logging-data="3428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19XTGn/MVwNa89FJTBl/l6IS7MwxFx9xuI=" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <05ed8053-be36-4332-8b75-7bca9afd65cc@googlegroups.com> Cancel-Lock: sha1:4vq1R95ydGF9HB6GQoMTM+LB4hM= Xref: news.eternal-september.org comp.lang.ada:46855 Date: 2017-05-22T23:24:08+02:00 List-Id: On 05/22/2017 12:46 AM, Jere wrote: > > I'll use a more concrete example here. I created a modal dialog box type > for Gnoga. My spec looks like: I gathered from your other posts that you were talking about this. > with Gnoga.Gui.Window; > with Gnoga.Gui.View; > package Gnoga.Gui.Modal_Dialog is > > type Dialog_Type is tagged limited private; > type Dialog_Access is access all Dialog_Type; > type Pointer_To_Dialog_Class is access all Dialog_Type'Class; > > procedure Create > (Dialog : in out Dialog_Type; > Parent : in out Gnoga.Gui.Window.Window_Type'Class; > ID : in String := ""); > > private > > type Dialog_Type is new Gnoga.Gui.View.View_Type with record > Main_View : Gnoga.Gui.View.View_Access := null; > end record; > > end Gnoga.Gui.Modal_Dialog; I don't see any reason for the access type in the full view. It could probably just be View_Type, but I think it should really be Gnoga.Gui.Element.Form.Form_Type, as I'll explain later. > At this point, I need a clean way to let a client > add components (Buttons, forms, etc.) to the dialog box. > > Adding all the operations to Dialog_Type won't help me > since all the components use a Create procedure that > takes a Gnoga.Gui.Base.Base_Type'Class parent. I don't > want to publicly expose the extension of Dialog_Type > since procedures like Create_From_HTML and such > will really mess with the Dialog_Type. Right. You need to be able control what the client can do with the dialog, so using a View_Access and providing it to the client is a Bad Idea. > The other option I was tossing around was to > instead add a > > procedure Add_Component > (Dialog : in out Dialog_Type; > Object : in out Gnoga.Gui.Base.Basetype'Class); Mostly what people need in such a dialog are buttons and text widgets (Text_Type). The former are from Gnoga.Gui.Element.Common and the latter from Gnoga.Gui.Element.Form, which is why I think your inner view should be a form. You can create buttons with a form as the parent, but you can't create a text widget without a form. (This seems wrong to me, but that's how Gnoga is. I've often used form widgets but never needed the form functionality.) So as a first cut you could only have procedure Create_Button (Button : in out Button_Type; Content : in String := ""; ID : in String := ""); procedure Create_Text (Text : in out Text_Type; Size : in Positive := 20; Value : in String := ""; Name : in String := ""; ID : in String := ""; Label : in String := ""); and you'd probably cover 95% of uses. Internally, you'd call Button.Create with your form as Parent, and Text.Create with your form as Form. Your client can then attach an on-click handler to the buttons and call Value for the text widgets. If Label is not null, you would create a label to go with Text with Label as its Content. You might also want to provide a Create_Div that the client could put a bunch of text into, and a New_Line for putting things on different lines. So you could have dialogs like +----------------------------------------+ | You have to authenticate to do that | | __________________________ | | Password: |__________________________| | | | | [ OK ] [ Cancel ] | +----------------------------------------+ Where the 1st line is a Div, the 2nd a Text_Type (or Password_Type; see below) with a label, and the 3rd 2 buttons. There are a bunch of specialized children of Text_Type, all with the same parameter profile for their Create procedures, so you could replace Text_Type with Text_Type'Class in Create_Text, and your client would get all of them. This would allow a Password_Type as mentioned above. Most of the things in Element.Common are descended from Base_Type, which doesn't have a Create, so you'd have to add others you think useful individually. Many things in Form are descended from Form_Element_Type, so you could provide type Kind_ID is (Button, Checkbox, Color, Date, Datetime, Datetime_Local, Email, File, Hidden, Image, Month, Number, Password, Radio, Range_ID, Reset, Search, Submit, Tel, Text, Time, Url, Week); procedure Create_Form_Item (Item : in out Form_Element_Type'Class; Item_Kind : in Kind_ID; Value : in String := ""; Name : in String := ""; ID : in String := ""); which would call Create_Element with an appropriate String for Input_Type. So you'd have to write a number of these Create operations, but there wouldn't be too many of them. I'd want to limit what kinds of things a client can put in a dialog, and maybe how many of them, too. But probably if you use Gnoga.Gui.Plugin.jQueryUI.Widget.Dialog_Type with Modal => True you can save yourself the effort. -- Jeff Carter "We call your door-opening request a silly thing." Monty Python & the Holy Grail 17