That makes sense, it's a good approach.
On Fri, Aug 6, 2010 at 3:17 PM, P T Withington <[email protected]> wrote:
> 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]
>
>
>
