Re: OFBiz Web Application won't load
Hi Dev team, Looking into this mail on user list, I think we should change the url '//localhost:8443/accounting' to 'https: //localhost:8443/accounting' at https://ofbiz.apache.org/developers.html - Best Regards, Swapnil M Mane www.hotwax.co On Mon, Jun 11, 2018 at 10:39 PM Rajesh Mallah wrote: > Hi Bharath , > > >> "localhost:8443/accounting" as in the instructions, but the browser > claims that the connection was reset. > > did you also try: > > https://localhost:8443/accounting > > regds > mallah. > > > On Mon, Jun 11, 2018 at 8:29 PM, bharathkay...@gmail.com < > bharathkay...@gmail.com> wrote: > > > Hi all, > > > > OS: Ubuntu 16.04 > > Java: OpenJDK 1.8.0_171 > > > > I downloaded and built OFBiz 16.11.04 around 6/7 using the instructions > > for developers (https://ofbiz.apache.org/developers.html). The > "./gradlew > > cleanAll loadDefault" command ran fine and took about 10 minutes (no > error > > messages/warnings during build, final message is "BUILD SUCCESSFUL"), but > > the "./gradlew ofbiz" command never quite seems to finish. To be sure, I > > let this command run as an active process for several hours before I > tried > > connecting to "localhost:8443/accounting" as in the instructions, but the > > browser claims that the connection was reset. Has anyone dealt with a > > similar issue, or does anyone see a problem? > > > > I made sure that the firewall rules were set such that port 8443 is open: > > netcat -z -v localhost 8443 > > Connection to localhost 8443 port [tcp/*] succeeded! > > > > And I know for sure that the application is listening on 8443: > > sudo netstat -tulpn > > Active Internet connections (only servers) > > Proto Recv-Q Send-Q Local Address Foreign Address State > > PID/Program name > > tcp6 0 0 :::8443 :::* > > LISTEN 4445/java > > > > Just to be sure, I tried navigating to ports 10523 and 8009 on localhost > - > > both of these prompted OFBiz to print some sort of acknowledgement to the > > console (either invalid message or connection received). All this > > information suggests to me that it's some sort of silly network issue > that > > I might be overlooking rather than a deeper, dependency-related issue. > > > > I looked at the thread titled "New Install won't run after server reboot" > > from 2018/05/09 but it didn't suggest much that would help me. Any help > > appreciated. > > >
Re: License issue with iText 4.2.0
There are 18 emails so far in this thread of which 13 are yours.
- You mentioned stuff from wikipedia
- then you mentioned stuff about licensing
- then you switched to birt
- then you talked about the author
- then you go back to questioning how to render PDFs in BIRT
- then you talk about your test logs for PDF rendering in BIRT (or
something like that)
- then you talk about the gradle cache
- then you talk about digital signatures
- then you talk about discussing things with apache legal
- then you ask people for their opinion
- then you go back to BIRT
So to answer your question, YES, it's very hard to read you :) Many of
your emails are long with lots of URLs and jump around multiple
topics. I personally cannot keep up, and that's why when you present a
question to the community, I have to ask you to pin down exactly what
you want.
Now back to this thread: I'm always in favor of completely removing
libraries where possible. This means refactoring CompDocServices.java
and PdfSurveyServices.java. I'm not sure how much work would that be,
but if it is a lot of work, then the work that I proposed might be a
quick fix for now (exclusion in gradle).
On Mon, Jun 11, 2018 at 8:25 PM, Jacques Le Roux
wrote:
> No, I'm suggesting to drop itext as a whole, not only itextpdf.
>
> Is it so difficult to read me :-o ?
>
> I 1st spoke about "itext/4.2.0" (not itextpdf at all). Then I suggested to
> remove "it".
>
> < Birt. Please confirm...>>
>
> I believe (it's no clear from Birt side) itext is something we drag from the
> 1st contribution of Birt in OFBiz. And Birt is now able to render PDF w/o
> itext.
> In some edge cases (at least: digital signature[1], 4 bytes UTF-8[2]) users
> would still need to use itext. See my previous last message for other
> details:
> < clearing the Gradle cache from all itext files>>
>
> Jacques
>
> [1] https://s.apache.org/b2sQ
>
> [2] https://s.apache.org/Ib78
>
>
>
> Le 11/06/2018 à 16:37, Taher Alkhateeb a écrit :
>>
>> I'm a bit lost. What are you _exactly_ proposing to do here? Are you
>> suggesting my exclusion syntax above (BTW better remove the version),
>> or are you suggesting something else?
>>
>> On Mon, Jun 11, 2018 at 3:10 PM, Jacques Le Roux
>> wrote:
>>>
>>> Le 08/06/2018 à 16:29, Jacques Le Roux a écrit :
Are we sure there are no legal issues doing so?
It seems OK at
https://mvnrepository.com/artifact/com.lowagie/itext/4.2.0
(MPL)
But reading
https://developers.itextpdf.com/question/versions-older-than-5
which applies also to 4.2.0 (see bottom "Some people claim that they use
iText 4.2.0, but that version has never been officially released") itext
seems a legal issue globally (not only itextpdf)
Maybe we should ask legal?
Also from few tests I did, it seems we don't need it to render PDF with
Birt. Please confirm...
>>>
>>>
>>> Did someone else tests?
>>> Since it works for me w/ "compile 'com.lowagie:itext" commented out
>>> after
>>> clearing the Gradle cache from all itext files I believe it should work
>>> for
>>> everyone else. Please confirm, should I open a Jira now?
>>>
>>> Now if users are of need of itext for other reasons (I found a couple of
>>> them Googling) they should take their responsibility. What are other
>>> opinions here?
>>>
>>> Jacques
>>>
>>>
Jacques
Le 08/06/2018 à 16:03, Scott Gray a écrit :
>
> Thanks Taher! Perfect simple solution.
>
> Regards
> Scott
>
> On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb,
> wrote:
>
>> So we exclude the transitive dependency in build.gradle and if
>> everything
>> works then we're fine.
>>
>> Syntax:
>>
>> compile('com.lowagie:itext:4.2.0') {
>> exclude 'com.itextpdf:itextpdf:5.5.6'
>> }
>>
>> On Fri, Jun 8, 2018, 11:40 AM Scott Gray
>>
>> wrote:
>>
>>> Hey Jacques,
>>>
>>> Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
>>
>> 4.2.0,
>>>
>>> does it make sense?
>>>
>>> Regards
>>> Scott
>>>
>>>
>>> On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,
>>> >>
>>> wrote:
>>>
I suggest this comment, a Jira seems appropriate
-compile 'com.lowagie:itext:4.2.0'
+compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because
of
license change
Jacques
Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
>
> Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
>>
>> Hi Scott,
>>
>> Reading Wikipedia It's OK as long as we don't update to a version
>>>
>>> = 5
https://en.wikipedia.org/wiki/IText
>
> Here is another source for MPL licensing:
https://www.eclipse.org/forums/index.php/t/175386/
>>
>> <> the
Re: License issue with iText 4.2.0
No, I'm suggesting to drop itext as a whole, not only itextpdf.
Is it so difficult to read me :-o ?
I 1st spoke about "itext/4.2.0" (not itextpdf at all). Then I suggested to remove
"it".
<>
I believe (it's no clear from Birt side) itext is something we drag from the
1st contribution of Birt in OFBiz. And Birt is now able to render PDF w/o itext.
In some edge cases (at least: digital signature[1], 4 bytes UTF-8[2]) users
would still need to use itext. See my previous last message for other details:
<>
Jacques
[1] https://s.apache.org/b2sQ
[2] https://s.apache.org/Ib78
Le 11/06/2018 à 16:37, Taher Alkhateeb a écrit :
I'm a bit lost. What are you _exactly_ proposing to do here? Are you
suggesting my exclusion syntax above (BTW better remove the version),
or are you suggesting something else?
On Mon, Jun 11, 2018 at 3:10 PM, Jacques Le Roux
wrote:
Le 08/06/2018 à 16:29, Jacques Le Roux a écrit :
Are we sure there are no legal issues doing so?
It seems OK at https://mvnrepository.com/artifact/com.lowagie/itext/4.2.0
(MPL)
But reading https://developers.itextpdf.com/question/versions-older-than-5
which applies also to 4.2.0 (see bottom "Some people claim that they use
iText 4.2.0, but that version has never been officially released") itext
seems a legal issue globally (not only itextpdf)
Maybe we should ask legal?
Also from few tests I did, it seems we don't need it to render PDF with
Birt. Please confirm...
Did someone else tests?
Since it works for me w/ "compile 'com.lowagie:itext" commented out after
clearing the Gradle cache from all itext files I believe it should work for
everyone else. Please confirm, should I open a Jira now?
Now if users are of need of itext for other reasons (I found a couple of
them Googling) they should take their responsibility. What are other
opinions here?
Jacques
Jacques
Le 08/06/2018 à 16:03, Scott Gray a écrit :
Thanks Taher! Perfect simple solution.
Regards
Scott
On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb,
wrote:
So we exclude the transitive dependency in build.gradle and if
everything
works then we're fine.
Syntax:
compile('com.lowagie:itext:4.2.0') {
exclude 'com.itextpdf:itextpdf:5.5.6'
}
On Fri, Jun 8, 2018, 11:40 AM Scott Gray
wrote:
Hey Jacques,
Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
4.2.0,
does it make sense?
Regards
Scott
On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,
I suggest this comment, a Jira seems appropriate
-compile 'com.lowagie:itext:4.2.0'
+compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because
of
license change
Jacques
Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
Hi Scott,
Reading Wikipedia It's OK as long as we don't update to a version
= 5
https://en.wikipedia.org/wiki/IText
Here is another source for MPL licensing:
https://www.eclipse.org/forums/index.php/t/175386/
<
Mozilla Public License <
https://en.wikipedia.org/wiki/Mozilla_Public_License>
or the GNU Library General Public License <
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open
source
licenses. However, as of version
5.0.0 (released Dec 7, 2009) it is distributed under the Affero
General
Public License
version
3.>>
MPL being OK as binary
Jacques
Le 08/06/2018 à 03:57, Scott Gray a écrit :
Hi All,
I just noticed that the iText maven bundle is a bit tricksy and
includes
iText 5.6.6 as a dependency, with the latter being GPL licensed.
You
can
see it by running "./gradlew -q dependencies":
+--- com.lowagie:itext:4.2.0
|\--- com.itextpdf:itextpdf:5.5.6
I haven't checked to see if the later version is actually used by
our
code
and I'm not sure if merely downloading it causes licensing issues,
but
I
thought I'd bring the question here in case anyone else has already
looked
into it. Not sure what the work-around would be if it is an issue.
Regards
Scott
Re: [Discussion] Introduction of Bootstrap and Vue.js
Hi,
Sorry to be late, but after reading https://alistapart.com/article/cult-of-the-complex I
wonder if we should not compare Bootstrap to "CSS Grid Layout"
Depending the less possible on frameworks seems a good idea to me, and the "CSS Grid
Layout" seems simple enough to be viable replacement.
Who knows when Bootstrap will be out of date...
Jacques
Le 20/05/2018 à 21:20, Jacques Le Roux a écrit :
That sounds realistic, pragmatic and to the point
+1
Jacques
Le 19/05/2018 à 20:31, Taher Alkhateeb a écrit :
This was a thought provoking and interesting discussion and I learned
new stuff from it, so thank you all for your valuable input.
On further reflection and after thinking about your comments, I think
Vue.js would be influenced in its design if we have a REST API in
place, however, something like Bootstrap is not relevant because it is
just a pure CSS / Javascript library to offer a grid system and some
user interface widgets. It has no model to bind to nor does it require
any back-end traffic (SPA stuff).
So I recommend proceeding with Bootstrap, and we can delay something
like Vue.js while we proceed in implementing the Web Services API.
I'll start or find another thread for that discussion.
WDYT?
On Fri, May 18, 2018 at 10:43 AM, innate Genius
wrote:
Hi,
+1 For Jacques, Scot & Rajesh’s View Point.
"I feel most of the modern UI frameworks consume JSON and
if we have yet another adapter to the rich catalog of WebServices
( in addition to XML/RPC and SOAP) it shall benefit both UI developers
and
system integrators / framework users."
This is been discussed in few other threads but this is a issue that is long
due. And would love to see the community to finally address this.
@Taher: Webservice to consume JSON would be the most beneficial and desired
enhancement to the framework.
Thx & Rgds,
Pratiek
On 17-May-2018, at 9:27 PM, Rajesh Mallah wrote:
Hi List ,
The default UI of OFBiz does look aged but I feel it does a great job
of being productive. As discussed before also ERP being a serious
backroom software and mostly operated by staff to whom all the bells
and whistles of modern frameworks may not make any difference.
But since adoption of OFBiz to enterprises is dependent on decision makers/
influencer who may not even know the nuances of UI and its relation to
productivity it is important to look modern and shiny and which is the
reason of
this thread by Mr. Taher.
Hence IMHO its good and required for OFBiz.
At the same time we need to increase the comfort level of system integrators
and people who use ofbiz as a framework.
I feel most of the modern UI frameworks consume JSON and
if we have yet another adapter to the rich catalog of WebServices
( in addition to XML/RPC and SOAP) it shall benefit both UI developers
and
system integrators / framework users.
I also humbly feel while this modernization is done, the existing interface
should
not be done away with as people develop very strange and innovative comfort
zones with software UIs which are difficult to anticipate by developers.
my 2cents.
regds
mallah.
On Wed, May 16, 2018 at 5:30 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Scott, Taher,
I think you are both right, and maybe because you are mostly working for 2
different markets or have different types of clients.
Anyway, what I mean is:
1. Form widgets are not of much use when you have to deploy a new UI for
an ecommerce or alike project (frontend).
2. They are very useful when you are working on a backend project (ie ERP
part) where people don't care much about bells and whistle (even if that's
less and less happening) but want a fast ROI ("time-to-market reasons"
as said Taher)
I don't know if Mathieu will get enough time to succeed on his project.
But obviously if we had the possibility to generate RESTful web services
from OFBiz services, with the export attribute like for SOAP and RMI, then
Scott's idea would be fulfilled and that would help much, not only in the
UI area of course.
Now for widgets, the form part could maybe slowly replaced by using tools
like Bootstrap and Vue.js. Or the new flavor in some years and that must be
very seriously taken into account to not have to redo it again, in few
years...
Jacques
Le 15/05/2018 à 12:18, Taher Alkhateeb a écrit :
Ahhh, I understand clearly now. Thank you!
So more or less, the heart of your message as I understand it is that
we should decouple the rendering of the user interface from data
fetching and manipulation. This makes perfect sense and is a good
strategy.
A bit contrary to your experience though, most of our work relies
heavily on the widget system for time-to-market reasons. It has been
immensely beneficial to get something out the door quickly. However,
of course the system falls short when it comes to heavy customizations
or the need to integrate with other systems.
So I would suggest that perhaps your comment in this thread that
"having
Re: License issue with iText 4.2.0
I'm a bit lost. What are you _exactly_ proposing to do here? Are you
suggesting my exclusion syntax above (BTW better remove the version),
or are you suggesting something else?
On Mon, Jun 11, 2018 at 3:10 PM, Jacques Le Roux
wrote:
> Le 08/06/2018 à 16:29, Jacques Le Roux a écrit :
>>
>> Are we sure there are no legal issues doing so?
>>
>> It seems OK at https://mvnrepository.com/artifact/com.lowagie/itext/4.2.0
>> (MPL)
>>
>> But reading https://developers.itextpdf.com/question/versions-older-than-5
>> which applies also to 4.2.0 (see bottom "Some people claim that they use
>> iText 4.2.0, but that version has never been officially released") itext
>> seems a legal issue globally (not only itextpdf)
>>
>> Maybe we should ask legal?
>>
>> Also from few tests I did, it seems we don't need it to render PDF with
>> Birt. Please confirm...
>
>
> Did someone else tests?
> Since it works for me w/ "compile 'com.lowagie:itext" commented out after
> clearing the Gradle cache from all itext files I believe it should work for
> everyone else. Please confirm, should I open a Jira now?
>
> Now if users are of need of itext for other reasons (I found a couple of
> them Googling) they should take their responsibility. What are other
> opinions here?
>
> Jacques
>
>
>>
>> Jacques
>>
>> Le 08/06/2018 à 16:03, Scott Gray a écrit :
>>>
>>> Thanks Taher! Perfect simple solution.
>>>
>>> Regards
>>> Scott
>>>
>>> On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb,
>>> wrote:
>>>
So we exclude the transitive dependency in build.gradle and if
everything
works then we're fine.
Syntax:
compile('com.lowagie:itext:4.2.0') {
exclude 'com.itextpdf:itextpdf:5.5.6'
}
On Fri, Jun 8, 2018, 11:40 AM Scott Gray
wrote:
> Hey Jacques,
>
> Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
4.2.0,
>
> does it make sense?
>
> Regards
> Scott
>
>
> On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,
>
> wrote:
>
>> I suggest this comment, a Jira seems appropriate
>>
>> -compile 'com.lowagie:itext:4.2.0'
>> +compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because
>> of
>> license change
>>
>> Jacques
>>
>>
>> Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
>>>
>>> Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
Hi Scott,
Reading Wikipedia It's OK as long as we don't update to a version
>
> = 5
>>
>> https://en.wikipedia.org/wiki/IText
>>>
>>> Here is another source for MPL licensing:
>>
>> https://www.eclipse.org/forums/index.php/t/175386/
<>
>> Mozilla Public License <
>> https://en.wikipedia.org/wiki/Mozilla_Public_License>
or the GNU Library General Public License <
>>
>> https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open
source
>>
>> licenses. However, as of version
5.0.0 (released Dec 7, 2009) it is distributed under the Affero
>
> General
>>
>> Public License
version
>>
>> 3.>>
MPL being OK as binary
Jacques
Le 08/06/2018 à 03:57, Scott Gray a écrit :
>
> Hi All,
>
> I just noticed that the iText maven bundle is a bit tricksy and
>>
>> includes
>
> iText 5.6.6 as a dependency, with the latter being GPL licensed.
You
>>
>> can
>
> see it by running "./gradlew -q dependencies":
> +--- com.lowagie:itext:4.2.0
> |\--- com.itextpdf:itextpdf:5.5.6
>
> I haven't checked to see if the later version is actually used by
our
>>
>> code
>
> and I'm not sure if merely downloading it causes licensing issues,
>
> but
>>
>> I
>
> thought I'd bring the question here in case anyone else has already
>>
>> looked
>
> into it. Not sure what the work-around would be if it is an issue.
>
> Regards
> Scott
>
>>>
>>
>>
>>
>
Re: License issue with iText 4.2.0
Le 08/06/2018 à 16:29, Jacques Le Roux a écrit :
Are we sure there are no legal issues doing so?
It seems OK at https://mvnrepository.com/artifact/com.lowagie/itext/4.2.0 (MPL)
But reading https://developers.itextpdf.com/question/versions-older-than-5 which applies also to 4.2.0 (see bottom "Some people claim that they use
iText 4.2.0, but that version has never been officially released") itext seems a legal issue globally (not only itextpdf)
Maybe we should ask legal?
Also from few tests I did, it seems we don't need it to render PDF with Birt.
Please confirm...
Did someone else tests?
Since it works for me w/ "compile 'com.lowagie:itext" commented out after clearing the Gradle cache from all itext files I believe it should work for
everyone else. Please confirm, should I open a Jira now?
Now if users are of need of itext for other reasons (I found a couple of them Googling) they should take their responsibility. What are other opinions
here?
Jacques
Jacques
Le 08/06/2018 à 16:03, Scott Gray a écrit :
Thanks Taher! Perfect simple solution.
Regards
Scott
On Fri, 8 Jun 2018, 23:19 Taher Alkhateeb,
wrote:
So we exclude the transitive dependency in build.gradle and if everything
works then we're fine.
Syntax:
compile('com.lowagie:itext:4.2.0') {
exclude 'com.itextpdf:itextpdf:5.5.6'
}
On Fri, Jun 8, 2018, 11:40 AM Scott Gray
wrote:
Hey Jacques,
Maybe I wasn't clear, OFBiz is downloading 5.5.6 as a dependency of
4.2.0,
does it make sense?
Regards
Scott
On Fri, 8 Jun 2018, 19:30 Jacques Le Roux,
I suggest this comment, a Jira seems appropriate
- compile 'com.lowagie:itext:4.2.0'
+ compile 'com.lowagie:itext:4.2.0' // don't update to 5+ because of
license change
Jacques
Le 08/06/2018 à 09:26, Jacques Le Roux a écrit :
Le 08/06/2018 à 09:24, Jacques Le Roux a écrit :
Hi Scott,
Reading Wikipedia It's OK as long as we don't update to a version
= 5
https://en.wikipedia.org/wiki/IText
Here is another source for MPL licensing:
https://www.eclipse.org/forums/index.php/t/175386/
<
Mozilla Public License <
https://en.wikipedia.org/wiki/Mozilla_Public_License>
or the GNU Library General Public License <
https://www.gnu.org/licenses/old-licenses/lgpl-2.0.en.html> open
source
licenses. However, as of version
5.0.0 (released Dec 7, 2009) it is distributed under the Affero
General
Public License
version
3.>>
MPL being OK as binary
Jacques
Le 08/06/2018 à 03:57, Scott Gray a écrit :
Hi All,
I just noticed that the iText maven bundle is a bit tricksy and
includes
iText 5.6.6 as a dependency, with the latter being GPL licensed.
You
can
see it by running "./gradlew -q dependencies":
+--- com.lowagie:itext:4.2.0
| \--- com.itextpdf:itextpdf:5.5.6
I haven't checked to see if the later version is actually used by
our
code
and I'm not sure if merely downloading it causes licensing issues,
but
I
thought I'd bring the question here in case anyone else has already
looked
into it. Not sure what the work-around would be if it is an issue.
Regards
Scott
gradle-versions-plugin OOTB?
Hi, I was wondering: some projects use the trunk or I guess more often a release branch as source. Should we not provide them a way to check the branch they use has the last libs versions using gradle-versions-plugin with a documented tasks, or should this stay (a bit buried) in one of our Jiras? I mean in a more global way, should we not document that for our users? Jacques
Re: svn commit: r1833231 - in /ofbiz/ofbiz-framework/trunk: framework/widget/dtd/ framework/widget/src/main/java/org/apache/ofbiz/widget/model/ framework/widget/src/main/java/org/apache/ofbiz/widget/r
Taher, Gil, Jacques, I've created the Jira ticket for the same: https://issues.apache.org/jira/browse/OFBIZ-10432 Will soon have someone to take care, thanks again for your help! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Mon, Jun 11, 2018 at 3:15 PM, Taher Alkhateeb wrote: > Yeah I apologize for making too much noise in this thread, perhaps it > would have been better discussed in JIRA. > > The reason I open these subjects up from time to time is to generally > try to unify code. Whenever I see an opportunity to unify the way > stuff works around the framework I cannot resist the temptation to at > least mention it. What you mentioned makes sense with respect to > combinations of "when" combined with either "text" or "display". > However it would be nice to do it also perhaps for interactive forms > with things like "container" fields or "include-form" directives > triggered by update events. > > In any case, I don't see a problem working with this for now as we > figure out better options. I just hope we don't get a lot of code > deployed on top of that before / if we decide to change it. > > On Mon, Jun 11, 2018 at 12:26 PM, Rishi Solanki > wrote: > > Thanks Taher, Gil, Jacques for you feedback. > > > > I'll get back and take your inputs into consideration and all seems > > acceptable to me. For Taher's point I remember we have use when and read > > only (display field) checks and ignored tag to make the field non > editable > > and non parameterized. This is only for brainstorming on the proposal. > And > > I tend to agree to apply this on all fields but for checkboxes we often > use > > disabled feature which is not applicable to all other type of inputs. > > > > I hope this would be fine, if we discuss this and slowly take care of > > suggestions after that. For Gil's suggestion I would change it asap. > > > > Thanks again for your help! > > > > > > Rishi Solanki > > Sr Manager, Enterprise Software Development > > HotWax Systems Pvt. Ltd. > > Direct: +91-9893287847 > > http://www.hotwaxsystems.com > > www.hotwax.co > > > > On Sun, Jun 10, 2018 at 1:37 PM, Jacques Le Roux < > > jacques.le.r...@les7arts.com> wrote: > > > >> +1 Gil > >> > >> Jacques > >> > >> > >> > >> Le 10/06/2018 à 08:34, Gil Portenseigne a écrit : > >> > >>> Hi Rishi, > >>> > >>> In the xsd it's better to use xs:boolean type, instead of enumeration > >>> type. > >>> > >>> Regards, > >>> > >>> Gil > >>> > >>> > >>> Le 9 juin 2018 14:34:49 GMT+02:00, ri...@apache.org a écrit : > >>> > Author: rishi > Date: Sat Jun 9 12:34:49 2018 > New Revision: 1833231 > > URL: http://svn.apache.org/viewvc?rev=1833231=rev > Log: > Improved: Add Support for Disable attribute in CheckBox Form Widget. > Disabled attrivute can be used as > > > > and default value for attribute will be false. > (OFBIZ-10367) > Thanks Pawan Verma for reporting the improvement and providing patch > for that. > Thanks James Yong for testing the work. > > Modified: > ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd > ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ > org/apache/ofbiz/widget/model/ModelFormField.java > ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ > org/apache/ofbiz/widget/model/XmlWidgetFieldVisitor.java > ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ > org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/CsvFormMacroLibrary.ftl > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/FoFormMacroLibrary.ftl > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/HtmlFormMacroLibrary.ftl > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/TextFormMacroLibrary.ftl > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/XlsFormMacroLibrary.ftl > ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac > ro/XmlFormMacroLibrary.ftl > > Modified: > ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd > URL: > http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra > mework/widget/dtd/widget-form.xsd?rev=1833231=1833230= > 1833231=diff > > == > --- ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd > (original) > +++ ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd > Sat Jun 9 12:34:49 2018 > @@ -956,6 +956,14 @@ under the License. > > > > + > + > + > +
Re: svn commit: r1833231 - in /ofbiz/ofbiz-framework/trunk: framework/widget/dtd/ framework/widget/src/main/java/org/apache/ofbiz/widget/model/ framework/widget/src/main/java/org/apache/ofbiz/widget/r
Yeah I apologize for making too much noise in this thread, perhaps it would have been better discussed in JIRA. The reason I open these subjects up from time to time is to generally try to unify code. Whenever I see an opportunity to unify the way stuff works around the framework I cannot resist the temptation to at least mention it. What you mentioned makes sense with respect to combinations of "when" combined with either "text" or "display". However it would be nice to do it also perhaps for interactive forms with things like "container" fields or "include-form" directives triggered by update events. In any case, I don't see a problem working with this for now as we figure out better options. I just hope we don't get a lot of code deployed on top of that before / if we decide to change it. On Mon, Jun 11, 2018 at 12:26 PM, Rishi Solanki wrote: > Thanks Taher, Gil, Jacques for you feedback. > > I'll get back and take your inputs into consideration and all seems > acceptable to me. For Taher's point I remember we have use when and read > only (display field) checks and ignored tag to make the field non editable > and non parameterized. This is only for brainstorming on the proposal. And > I tend to agree to apply this on all fields but for checkboxes we often use > disabled feature which is not applicable to all other type of inputs. > > I hope this would be fine, if we discuss this and slowly take care of > suggestions after that. For Gil's suggestion I would change it asap. > > Thanks again for your help! > > > Rishi Solanki > Sr Manager, Enterprise Software Development > HotWax Systems Pvt. Ltd. > Direct: +91-9893287847 > http://www.hotwaxsystems.com > www.hotwax.co > > On Sun, Jun 10, 2018 at 1:37 PM, Jacques Le Roux < > jacques.le.r...@les7arts.com> wrote: > >> +1 Gil >> >> Jacques >> >> >> >> Le 10/06/2018 à 08:34, Gil Portenseigne a écrit : >> >>> Hi Rishi, >>> >>> In the xsd it's better to use xs:boolean type, instead of enumeration >>> type. >>> >>> Regards, >>> >>> Gil >>> >>> >>> Le 9 juin 2018 14:34:49 GMT+02:00, ri...@apache.org a écrit : >>> Author: rishi Date: Sat Jun 9 12:34:49 2018 New Revision: 1833231 URL: http://svn.apache.org/viewvc?rev=1833231=rev Log: Improved: Add Support for Disable attribute in CheckBox Form Widget. Disabled attrivute can be used as and default value for attribute will be false. (OFBIZ-10367) Thanks Pawan Verma for reporting the improvement and providing patch for that. Thanks James Yong for testing the work. Modified: ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ org/apache/ofbiz/widget/model/ModelFormField.java ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ org/apache/ofbiz/widget/model/XmlWidgetFieldVisitor.java ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/CsvFormMacroLibrary.ftl ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/FoFormMacroLibrary.ftl ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/HtmlFormMacroLibrary.ftl ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/TextFormMacroLibrary.ftl ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/XlsFormMacroLibrary.ftl ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac ro/XmlFormMacroLibrary.ftl Modified: ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra mework/widget/dtd/widget-form.xsd?rev=1833231=1833230= 1833231=diff == --- ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd (original) +++ ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd Sat Jun 9 12:34:49 2018 @@ -956,6 +956,14 @@ under the License. + + + + + + + + Modified: ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/ org/apache/ofbiz/widget/model/ModelFormField.java URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra mework/widget/src/main/java/org/apache/ofbiz/widget/model/ ModelFormField.java?rev=1833231=1833230=1833231=diff == ---
Re: svn commit: r1833231 - in /ofbiz/ofbiz-framework/trunk: framework/widget/dtd/ framework/widget/src/main/java/org/apache/ofbiz/widget/model/ framework/widget/src/main/java/org/apache/ofbiz/widget/r
Thanks Taher, Gil, Jacques for you feedback.
I'll get back and take your inputs into consideration and all seems
acceptable to me. For Taher's point I remember we have use when and read
only (display field) checks and ignored tag to make the field non editable
and non parameterized. This is only for brainstorming on the proposal. And
I tend to agree to apply this on all fields but for checkboxes we often use
disabled feature which is not applicable to all other type of inputs.
I hope this would be fine, if we discuss this and slowly take care of
suggestions after that. For Gil's suggestion I would change it asap.
Thanks again for your help!
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co
On Sun, Jun 10, 2018 at 1:37 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> +1 Gil
>
> Jacques
>
>
>
> Le 10/06/2018 à 08:34, Gil Portenseigne a écrit :
>
>> Hi Rishi,
>>
>> In the xsd it's better to use xs:boolean type, instead of enumeration
>> type.
>>
>> Regards,
>>
>> Gil
>>
>>
>> Le 9 juin 2018 14:34:49 GMT+02:00, ri...@apache.org a écrit :
>>
>>> Author: rishi
>>> Date: Sat Jun 9 12:34:49 2018
>>> New Revision: 1833231
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1833231=rev
>>> Log:
>>> Improved: Add Support for Disable attribute in CheckBox Form Widget.
>>> Disabled attrivute can be used as
>>>
>>>
>>>
>>> and default value for attribute will be false.
>>> (OFBIZ-10367)
>>> Thanks Pawan Verma for reporting the improvement and providing patch
>>> for that.
>>> Thanks James Yong for testing the work.
>>>
>>> Modified:
>>> ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/model/ModelFormField.java
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/model/XmlWidgetFieldVisitor.java
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/renderer/macro/MacroFormRenderer.java
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/CsvFormMacroLibrary.ftl
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/FoFormMacroLibrary.ftl
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/HtmlFormMacroLibrary.ftl
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/TextFormMacroLibrary.ftl
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/XlsFormMacroLibrary.ftl
>>> ofbiz/ofbiz-framework/trunk/themes/common-theme/template/mac
>>> ro/XmlFormMacroLibrary.ftl
>>>
>>> Modified:
>>> ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>> mework/widget/dtd/widget-form.xsd?rev=1833231=1833230=
>>> 1833231=diff
>>>
>>> ==
>>> --- ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd
>>> (original)
>>> +++ ofbiz/ofbiz-framework/trunk/framework/widget/dtd/widget-form.xsd
>>> Sat Jun 9 12:34:49 2018
>>> @@ -956,6 +956,14 @@ under the License.
>>>
>>>
>>>
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>> +
>>>
>>>
>>>
>>>
>>> Modified:
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/model/ModelFormField.java
>>> URL:
>>> http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/fra
>>> mework/widget/src/main/java/org/apache/ofbiz/widget/model/
>>> ModelFormField.java?rev=1833231=1833230=1833231=diff
>>>
>>> ==
>>> ---
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/model/ModelFormField.java
>>> (original)
>>> +++
>>> ofbiz/ofbiz-framework/trunk/framework/widget/src/main/java/
>>> org/apache/ofbiz/widget/model/ModelFormField.java
>>> Sat Jun 9 12:34:49 2018
>>> @@ -980,25 +980,30 @@ public class ModelFormField {
>>> public static class CheckField extends FieldInfoWithOptions {
>>>public final static String ROW_SUBMIT_FIELD_NAME = "_rowSubmit";
>>> private final FlexibleStringExpander allChecked;
>>> +private final boolean disabled;
>>>
>>> private CheckField(CheckField original, ModelFormField modelFormField)
>>> {
>>> super(original, modelFormField);
>>> this.allChecked = original.allChecked;
>>> +this.disabled = original.disabled;
>>> }
>>>
>>> public CheckField(Element element, ModelFormField modelFormField) {
>>> super(element, modelFormField);
>>> allChecked =
>>>
