Thanks for your fast response.
I think i ended up a bit ranty, so I put it under a hidden part. I tried to already edit for brevity but it ended up pretty long. Apologies.
I guess it's these points in summary:
- valid input data is essential to have the front end work.
- Parsing user string input is hard
- valid data is also hard to add if we don't have the required drop downs for the wiki interface
- Is it worthwhile investing logic in string parsing existing fields in the database, or is that better served on on improving database itself
- how are PoE PSE's handled? I see issues with parsing power supplies especially
- I already made a topic asking for assistance from a wiki admin regarding updating the wiki forms. I offered assistance in updating documentation on how to add to ToH hwdata.
- Is tmomas available by forum still? I'd appreciate it if you could help get me in contact with a wiki admin. edit: looking at the new wiki account forum post, need to go for IRC? So I've tried that today...
Further discussion & images
No worries. Wasn't implying saying we need to go and modify existing columns.
I just think that changing the front end to do string parsing on text fields is also hard.
I don't know whether that's better than the other existing infrastructure where you can control click
options.
Bad input / not well defined data plus adding string parsing on top will result in inconsistent results even if we revamp the front end.
At least I believe It's worthwhile to discuss whether parsing the existing database is a "workaround" or the best path forward?
Or is doing improvements on the source data set better?
mm.
There is existing documentation on the wiki that if you want a field added to an existing column, you need to contact the wiki admin and create a new forum topic in the documentation section.
https://openwrt.org/meta/create_new_dataentry_page
Already made a thread:
HPE (or adding a new) brand on create new device entry page?
I already did that regarding HPE as a drop down for brand, as well as asking how the existing data ended up correct without a switch drop down and "hpe" brand drop down....
Your feedback regarding "if you have a problem with it you should do it yourself" is valid haha =)
Already offered in the other forum post....
Plus I gave it a go and ended up with causing an inconsistent data problem....
My experience with dokuwiki as anything but a user approximates zero.
I've hosted other web applicaions before, but not my strong suit.
I could certainly give it a go.
I think the approach there is to minimise
the cost of failure. Hence ask for help first....
Comes down to time IMO, I'd rather work on hardware than websites though =P I don't want to leave a mess for other people to clean up though.
I also don't want to break the wiki rules.
It appears the existing instructions for getting things into ToH can create issues if it's a switch and if it's not an existing brand.
Hence I did as instructed and posted on the forum asking the existing wiki admins for columns/forms to be updated?
At the moment when trying to add data, you can end up with inconsistent data.
I would suggest a parallel path to a better table of hardware is to make sure that data is easy to enter/correct as well as consistent?
I understand well that this is obviously volunteer time......
Not trying to say what "should" or "must" be changed. Nor saying "just" do this or "just" do that =P.
OP asking for feedback and questions and adding my unsolicited feedback haha.
Regarding backwards incompatibilities.
We currently don't have mounting options, nor dimensions as a column?
We do have an "outdoor" / indoor column?
I fail to see how you can get inconsistent data if the data doesn't exist.
(other than the fact that there will be empty fields, which is of course a problem with existing/all fields).
I do see the issue where if you add new columns without deprecating or doing a huge effort in manual/automatic parsing to move to a new schema you could just add to the inconsistent data problem in the short term....
My existing question still remains, how should/is this implementation going to handle multiple power supply types?
Looks like there's no OR or AND functionality like the statement above regarding parametric search.
(Better and faster) Table of Hardware - #23 by Search
I think that the parametric search and other types like that can be frustrating as you need to control click
lots of things and less than greater than on the string fields with units can give bad/inconsistent results. (i.e. power supplies would be a good example here, many terms including VAC, ~, AC, VDC, DC, "V", VRMS, mah, Wh, USB, PoE, PD, PoE Powered Device, IEC C13, IEC C10, IEC C15, IEC C8, IEC C7)
I would say yes regarding inconsistent data haha.
So it comes down to if you're willing to do string parsing to improve the front end. One still need good input data, or you end up having to do lots of exceptions etc.
I believe this power supply approach yields inconsistent results at the moment?
I can get the HPE PoE switches coming up as a PoE powered device for example?
Please see screen captures:
