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
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 not
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
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 JavaScript
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
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
