I have this suggestion for back-compatibility:
If there is a parameter named lzoptions, it is the new way, and that is the
only thing you look for. If there is not a parameter named lzoptions, it is
the old way, and you do "compatibility mode". I suggest _not_ sharing code
between the two paths. This is a case where I think copy/paste is the right
approach. We'd have a structure something like:
if (<found lzoptions>) {
// The new way... with a clean implementation
} else {
// Legacy code, delete in 6.0
}
On 2010-08-06, at 08:59, Henry Minsky wrote:
> I'm up for finally implementing this. We can be back compatible until LPS
> 6.0 I guess.
>
>
>
> On Fri, Aug 6, 2010 at 7:52 AM, P T Withington <[email protected]> wrote:
>
>> When doing this, please, please, please consider implementing the ideas in:
>>
>> http://jira.openlaszlo.org/jira/browse/LPP-3479
>>
>> before we clutter the query-arg namespace further. Maybe rather than
>> renaming `lzt` (for LZ request Type), to `wrapper`, we should use something
>> more generic like `package`? (Open to suggestions for better names!) Don's
>> suggestion on LPP-3749 would allow multiple parameters for the package
>> option, for example:
>>
>> ?lzoptions=runtime(html5),package(widget,jil)
>>
>> or,
>>
>> ?lzoptions=runtime(swf10),package(widget,android)
>>
>> [Every time we add a new option we take away from the query-arg parameters
>> namespace, and we have to go find all the places in the wrappers and the
>> compiler where we sort and filter and pass on the options to the app. We
>> always make the excuse that we don't have time to implement the right
>> solution. But _someday_ we really need to clean this up. And this seems
>> like a nice opportunity to do that, especially given the need for multiple
>> parameters for the widget packaging.]
>>
>> On 2010-08-06, at 05:09, Raju Bitter wrote:
>>
>>> Henry,
>>>
>>> do you think the widget should be rendered into the same directory?
>>> Say my url is:
>>>
>>> localhost:8080/olserver/somemapp/app.lzx?lzt=widget
>>>
>>> If we generate all the widget files into the same folder as the
>>> application, that would be technically the easiest solution, since no
>>> redirect is involved. But if we have different widget types (Opera,
>>> W3C, JIL), and we'd attacht a ?lzt=widget&widgettype=jil, maybe it
>>> would be better to create a subfolder (opera,w3cwidget,jil), and place
>>> all the files into that folder. Then send a redirect to the newly
>>> create or already existing widget folder. The idea is really to have a
>>> URL stored in your browser favorites, and to be able to point
>>> Chrome/Ripple to just that URL and automatically load the widget into
>>> the emulator.
>>>
>>> If we support &widgetttype=???, the convention could be: We have
>>> templates for Opera, JIL, Bondi and W3C widget in the
>>> lps/widgets/templates folder. Those would be used to generate the
>>> widget, unless the user creates a custom config.xml in the same folder
>>> where the LZX file lives. Convention would be:
>>>
>>> ?lzt=widget&widgettype=jil > looks for a jil.config.xml in the LZX folder
>>> ?lzt=widget&widgettype=opera > looks for a opera.config.xml in the LZX
>> folder
>>> ?lzt=widget&widgettype=w3cwidget > looks for a w3cwidget.config.xml in
>>> the LZX folder
>>> and so one. If we have a new widget standards coming up, that
>>> mechanism could be easily extended.
>>>
>>>
>>> On Fri, Aug 6, 2010 at 4:15 AM, Henry Minsky <[email protected]>
>> wrote:
>>>> we could do that...
>>>>
>>>> On Thu, Aug 5, 2010 at 8:26 PM, P T Withington <[email protected]> wrote:
>>>>>
>>>>> I like that idea! lzt=widget
>>>>>
>>>>> On 2010-08-05, at 19:01, Raju Bitter wrote:
>>>>>
>>>>>> Yes, agree with Tucker. If you want a SOLO app, an index.html is a
>>>>>> good option as well.
>>>>>>
>>>>>> But when you are testing widgets, it would come in handy to be able to
>>>>>> generate the whole widget packet exploded into one folder, returning
>>>>>> the config.xml. That's the way you could directly load an OL app into
>>>>>> a browser emulator like Ripple. Using lzt=widget for example.
>>>>>>
>>>>>> On Thu, Aug 5, 2010 at 9:37 PM, P T Withington <[email protected]> wrote:
>>>>>>> Yes we should do this.
>>>>>>>
>>>>>>> See http://jira.openlaszlo.org/jira/browse/LPP-9148
>>>>>>>
>>>>>>> I think it is right to use index.html. It seems much more likely
>> that
>>>>>>> someone will be making a widget than a solo app. If they are really
>> making
>>>>>>> a solo app, they are more likely to be writing a custom wrapper page.
>>>>>>>
>>>>>>> On 2010-08-05, at 15:32, Henry Minsky wrote:
>>>>>>>
>>>>>>>> The W3C widget format is a standard, and very close to what we're
>>>>>>>> emitting
>>>>>>>> for SOLO zip archives.
>>>>>>>>
>>>>>>>> Should we just switch the SOLO deployer scripts over to the W3C
>> format
>>>>>>>> ?
>>>>>>>>
>>>>>>>> The only difference that I can see at the moment Opera (the only
>>>>>>>> browser
>>>>>>>> that runs widgets that I know of)
>>>>>>>> requires currently that the start file be named as "index.html",
>>>>>>>> whereas
>>>>>>>> we've been making the solo deployer generate
>>>>>>>> a file named "yourapp.lzx.html".
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Henry Minsky
>>>>>>>> Software Architect
>>>>>>>> [email protected]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> [email protected]
>>>>
>>>>
>>>>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> [email protected]
