Opened 4 years ago

Closed 4 years ago

#4115 closed enhancement (duplicate)

unparse routine for classification expressions

Reported by: fdupont Owned by: UnAssigned
Priority: medium Milestone: Outstanding Tasks
Component: configuration Version: git
Keywords: classification Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by fdupont)

Looking at #4088 proposal I found a getCode() method for TokenOption used for testing. IMHO we need more, i.e., an "unparse" routine (new virtual method of Token class) which returns something related (not necessary equal) to the parser input.

Subtickets

Change History (12)

comment:1 Changed 4 years ago by fdupont

I refine this:

  • new toText() virtual method for tokens.
  • new decompiler() function on expression (highly recursive of course).

comment:2 Changed 4 years ago by fdupont

  • Owner set to fdupont
  • Status changed from new to accepted

comment:3 Changed 4 years ago by fdupont

  • Owner changed from fdupont to UnAssigned
  • Status changed from accepted to reviewing

Done in 2 commits. Ready for review.

comment:4 Changed 4 years ago by fdupont

BTW the toText() function allows an easy comparison between 2 expressions (something we need for #4088) as TokenString(foo).toText() returns (notice the quotes) 'foo' so there is no possible ambiguity.

comment:5 Changed 4 years ago by fdupont

I updated the branch (and the tag) by merging trac4091 from master.
Still to be reviewed.

comment:6 Changed 4 years ago by hschempf

  • Milestone changed from Kea-proposed to DHCP Outstanding Tasks

comment:7 Changed 4 years ago by fdupont

Updated to the new syntax. Note it is in competition with #4124?

comment:8 Changed 4 years ago by fdupont

  • Description modified (diff)

Branched into trac4115 for the new option syntax (aka #4093).

comment:9 follow-up: Changed 4 years ago by marcin

It seems odd that we're working on implementation of this ticket while we also have #4124, which solves it in a different way. I'd think that we should decide which way to go and then implement stuff.

I point out that there will be expressions like "option[dns-servers].text" which may be easier to keep as original text rather than unparse, which may require matching option code with option name (depending how this is evetually implemented).

comment:10 in reply to: ↑ 9 Changed 4 years ago by fdupont

Replying to marcin:

It seems odd that we're working on implementation of this ticket while we also have #4124, which solves it in a different way. I'd think that we should decide which way to go and then implement stuff.

I point out that there will be expressions like "option[dns-servers].text" which may be easier to keep as original text rather than unparse, which may require matching option code with option name (depending how this is evetually implemented).

=> it'd depends on whether we need the exact input or just enough to rebuild the expression (note we add the same discussion about integers). BTW there is the decompile code which is mostly independent (it requires a token -> string method but any can be used if it provides token -> string -> token is the identity).
Note #4115 is already implemented in trac4115a so it is enough to adopt the ticket and to review it...

comment:11 Changed 4 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

comment:12 Changed 4 years ago by fdupont

  • Resolution set to duplicate
  • Status changed from reviewing to closed

Closing this ticket by replacing by a decompile one (#4240).

Note: See TracTickets for help on using tickets.