Hi,
I think this is a good idea. Though, it isn't the 'break-up' I imagined
when I first started reading your message. I just assumed the LuCI webif
was minimal with the option of adding tabs -- much like the original
webif.
I suppose the questions I still have about the LuCI webif project are:
Hello Everyone,
much work has been done this week and thanks to your feedback and opinions we
are happy to inform you about the latest project updates.
After the recent discussions about user-friendly vs. full-featured interfaces
we decided to split up LuCI into two parts "LuCI Administration"
> Sorry, but in some respects I look at all these web interfaces and just
> cringe; the webif was never meant to be a lifelong ambition, it should
> only be a very thin layer between uci and the browser. All of the schema
> and validation, as well as the i18n should actually be handled on the
> uci
On Tue, Jul 15, 2008 at 01:58:05PM +0200, wlanmac wrote:
> The concept of having configurations in XML could help. It's a bit
> easier to make rigid definitions, version these definitions, create
> off-line syntax checkers, and render the data in all sorts of
> formats...
Sorry, but in some respe
> I thought Gargoyle was interesting, although my money is on serving the
> config files as xml, using xslt to do the presentation layer parsing the
> xml-ified config files to html+css and then using ajax calls to pass
> back the data. As a result, there would be a single url per /etc/config
> fi
On Tue, Jul 15, 2008 at 12:38:24PM +0200, wlanmac wrote:
> > But if you are using the Gargoyle approach - that is not bad but simply a
> > different approach - you have to mess up with Shell and learn JavaScript or
> > in your case *yourFrontendLanguage*.
> >
>
> True. But, I'd argue that Java
> Yeah, sounds like many scripting languages...
except shell ;-)
> Agreed, there is always some distribution specific glue needed. I'm
> leaning toward a 'meta configuration' (in XML) which can be edited,
> verified, and translated into distro specific configurations.
Ah I see you added another ab
> It's just a separate set of packages: not more, not less.
>
Ok, cool.
> But if you are using the Gargoyle approach - that is not bad but simply a
> different approach - you have to mess up with Shell and learn JavaScript or
> in your case *yourFrontendLanguage*.
>
True. But, I'd argue tha
Hello wlanmac,
at first thank you for your feedback.
> will it be difficult to remove overall or will the LuCI code be mixed up
> with non-GUI scripts?
It's just a separate set of packages: not more, not less.
> As for LuCI, I would like to know more about why Lua and hence LuCI? You
> say "It's
Hi,
Sounds good, but perhaps not for everyone. This will be integrated into
the main firmware or will it always be a package? I'm not concerned
about it being installed per default in the OpenWrt-built firmware, but
will it be difficult to remove overall or will the LuCI code be mixed up
with non-
Hello Everyone,
you may have noticed "LuCI the Lua Configuration Interface" in the official
release announcement for Kamikaze 8.08
As there was not much information about this project in the past and we
noticed several people asking in different places for it we like to make a
little announceme
11 matches
Mail list logo
